GitHub Actions - Getting Started With Environments 

Thanks for watching and for the feedback!

Thank you!

Thanks for watching!

Awesome, thank you!

That is a tricky question, which falls into your process. Some people like GitFlow, I'm more of a GitHubFlow type of person, because it does trunk based development in a way that I like.

Thank you for the feedback. You access them just like you do any other secret: ${{secrets.MY_SECRET_NAME_HERE}}. The catch is, you will only be able to access the environment secret if the job is targeting that environment

why not do this at the workflow scope, or at least allow us to specify multiple environments per job? @@MickeyGousset

Thanks for watching and commenting!

Unfortunately the classic answer is "it depends". It is really going to depend on what your process is for being able to move from one environment to another. Unit testing, in my opinion, is something that must pass BEFORE you even push to the main branch, so it needs to occur during the pull request. Now it should also occur again any time you are doing a build, so, for example, if you are deploying to your DEV environment every time there is a push to main, you want to include unit testing in the build, to make sure everything is OK. Now, as far as what needs to be met to go from DEV to QA to PROD, it really depends on the organization and the process. Some customers I have worked with have a 24 hour wait period before they can move from one environment to the next. And if you have a QA env before a PROD one, then i'm sure there are manual or automated tests that also need to pass before you would want to move into PROD. This would make a good question/discussion on the GitHub subreddit.

@@MickeyGoussetyeah, i am actually starting with a project where i already define my ci/cd pipeline to deploy a docker image into kubernetes and one requirement is to create a dev, qa and prod environment. I think i will have to research what kind of tests needs to be addressed between QA and prod, because if I am already covering what i think is more important in my CI/CD, i am not sure what needs to be tested in those environments. Thanks mickey, this is a really wonderful topic to cover.

@@danielt5542 usually the testing from QA to PROD is whatever you need to do to make yourself feel confident that you can deploy the code, and is usually a mixture of manual and automated tests. That said, if you want to send me an email at mickeygousset@github.com, with some details of what you are deploying and any other information you might find relevant, I'll throw it at some people on my team who know way more than I do about containers and K8S and see how they might answer the question.

Multiple jobs can point to the same environment. But a job can only point to one environment at a time

I think you would need to check, in the job that is doing the deployment, that everything is ok. If it isn't, then you could have a step that just does an "exit 1", which will cause the step and the job to fail, and can fail the future jobs.

If you add the environment to your job and it doesn’t exist then it will create it. But you can’t configure the environment from YAMl

The environments are created at the repository level. You can see the use of environments at the job step, there is a keyword "environment" which then specifies the environment you are pointing the job at.

They are available for public eepos

Without an enterprise plan

Good feedback thank you. I’m planning to update the video I’ll take that into consideration

@@MickeyGousset the video is great nevertheless, thanks!