✨ *Question of the day* ✨: Do you like these new features? How do you plan to use them? 🆘 NEED HELP? 🆘 Book a 1:1 Consultation with CoderDave: geni.us/cdconsult We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with! 🙏🏻SUPPORT THE CHANNEL🙏🏻 Buy me a coffee: www.buymeacoffee.com/CoderDave PayPal me donation: paypal.me/dabenveg
Hello, thank you for explanation. I have a question for you please. Who transfer the code between environments? For example when developers done their codes who pushes to test environment and when testers done who pushes codes to next environment? And who creates these environments on GitHub in real projects? Thanks in advance.
Hey, happy it's been helpful About your questions is a matter of process... in many processes, no-one pushes the code... the code is pushed to the branch once... and build once, the build creates what is know as artifact (basically the result of the build, which could be a zip file, a binary, or anything that you can deploy) and then a job in the workflow deploys that artifact to the first environment (let's say Dev). if changes need to be made, the current run is invalidated, changes are made, and a new updated artifact is deployed to Dev. when the status is ok, you can approve the next deployment and a new job in teh same workflow will deploy THE SAME ARTIFACT to the next environment, and so on so forth. It is very important to note I said "the same artifact". This means that there is no build or code change between environments. The application is built once, and then the exact same binaries are deployed to the different environments (this ensure that if a binary was working in QA, it will work in staging, prod, etc because no code is changed) About the "who creates the environments", well again it depends... could be a Release manager, the DevOps team, or anyone else with enough permissions
Hi Dave, thanks for a great overview. Do you perhaps know if one step or job requiring approval, say Production, was once approved will this approval be inherited by consequent steps and jobs in the same workflow? Basically speaking, am I approving a particular step or the whole workflow?
Happy you found this helpful. The approval is set on the environment, and the environment is set at Job level. Therefore the approval is at job level, meaning that once approved all the steps in the job will be executed.
Thanks for replying. Yeah, although I understand the logic behind, was a little upset when found this out by trials and errors. I wanted to approve 2 reusable workflows running on same environment at once. Eventually, needed to introduce separate job in front for the purpose of approval.
Thanks. Do you mean the "GitHub Releases"? If so, it is not possible to deploy the releases directly (they are basically a "storage" to fix in time whatever artifact you want. But you can have an Action workflow triggered by a release creation. In the workflow you could read the content of the release and therefore use that artifact to deploy to the environment you want.
Question about what you discuss at the 12:00 mark: I created an environment. Then I clicked the code view, on the right where your screen shows Releases, Packages, and Environments mine shows Releases, Packages, and Languages. I did not actually build and deploy to the Environment, I simply created and configured one Environment. Could that be why? Maybe a build and deployment is required? Thanks for any info.
Hey liked the video a lot and left a like. These new features sound like they would definitely help an agile team. But quick question. How does environment protection work with mid + sized team if you have multiple developers working on different tasks in the same repo? Lets say dev one checks in code and is waiting approval and while waiting dev 2 checks in his code and is then awaiting approval as well. What is the behavior of Github Actions pipeline in this state?
If a deployment A is waiting for approval in an environment, and another deployment B is queued for the same environment you''ll have it both waiting for approval. Then it is a matter of which one you approve first. Anyway, the other will still be in waiting state until you either approve it or cancel it.
Is it a private repo? If so it is normal, environments are available only on public repos. If you want to have them on private repos you need to be on GitHub Enterprise 😕
Yes, that’s correct. I believe I mention this also in the video, Environments are available only for public repos. If you have GitHub Enterprise, then it’s available also on private repos.
How do I disable email notification for the review deployments approval,as I donot need email notification, is there any settings to do this at organization level instead of manually unsubscribing it can we do it in settings?
Hey can u pls lemme know if we can modify If a job is not approved within 30 days, the workflow run will be automatically canceled. 30days to lesser number and how?
Unfortunately, this is not available for private repos on either personal account or teams plan :( GitHub has decided to make this available on private repos only in the GitHub Enterprise Cloud (GHEC) :( If you are on private repos but not on GHEC, then you'd need to use some kind of workaround
Not sure what you mean. You still have the deployment steps for your environments/servers/targets in the workflow. The Environment section of the job specifications allows you to control things like environment-specific secrets, approvals, etc
✨ *Question of the day* ✨: Do you like these new features? How do you plan to use them?
🆘 NEED HELP? 🆘
Book a 1:1 Consultation with CoderDave: geni.us/cdconsult
We can talk about GitHub, Azure DevOps, or any other DevOps tool or project you need help with!
🙏🏻SUPPORT THE CHANNEL🙏🏻
Buy me a coffee: www.buymeacoffee.com/CoderDave
PayPal me donation: paypal.me/dabenveg
Keep your content coming- -appreciate it
Thanks, I definitely will ☺️
Thanks for sharing this video.. really like
Thanks! What do you like the most in the video?
Thanks! love the detail explanation. Now this is added to my favorite 😎👍
Thanks to you! Merry Christmas if you celebrate it and happy new year 🎊
Great tutorial! It showed me how to review deployment jobs. Thanks a lot! Benny
Glad it was helpful!
Hello, thank you for explanation. I have a question for you please. Who transfer the code between environments? For example when developers done their codes who pushes to test environment and when testers done who pushes codes to next environment? And who creates these environments on GitHub in real projects? Thanks in advance.
Hey, happy it's been helpful
About your questions is a matter of process... in many processes, no-one pushes the code... the code is pushed to the branch once... and build once, the build creates what is know as artifact (basically the result of the build, which could be a zip file, a binary, or anything that you can deploy) and then a job in the workflow deploys that artifact to the first environment (let's say Dev).
if changes need to be made, the current run is invalidated, changes are made, and a new updated artifact is deployed to Dev.
when the status is ok, you can approve the next deployment and a new job in teh same workflow will deploy THE SAME ARTIFACT to the next environment, and so on so forth.
It is very important to note I said "the same artifact". This means that there is no build or code change between environments. The application is built once, and then the exact same binaries are deployed to the different environments (this ensure that if a binary was working in QA, it will work in staging, prod, etc because no code is changed)
About the "who creates the environments", well again it depends... could be a Release manager, the DevOps team, or anyone else with enough permissions
great tutorial
Thank you! Cheers!
Very informative. Thank you for sharing!
Glad you enjoyed it!
Thank you mate! very useful!
Glad it helped!
Great video, it’s very cool feature. Shame you need an enterprise subscription, seems a pretty common requirement even for small teams
Very true!
Hi Dave, thanks for a great overview. Do you perhaps know if one step or job requiring approval, say Production, was once approved will this approval be inherited by consequent steps and jobs in the same workflow? Basically speaking, am I approving a particular step or the whole workflow?
Happy you found this helpful. The approval is set on the environment, and the environment is set at Job level. Therefore the approval is at job level, meaning that once approved all the steps in the job will be executed.
Thanks for replying. Yeah, although I understand the logic behind, was a little upset when found this out by trials and errors.
I wanted to approve 2 reusable workflows running on same environment at once. Eventually, needed to introduce separate job in front for the purpose of approval.
Great video.
Does anyone know if its possible to deploy releases to specific environments?
Thanks. Do you mean the "GitHub Releases"? If so, it is not possible to deploy the releases directly (they are basically a "storage" to fix in time whatever artifact you want. But you can have an Action workflow triggered by a release creation. In the workflow you could read the content of the release and therefore use that artifact to deploy to the environment you want.
Thanks Good explanation.
Thanks, happy you liked it ☺️
Question about what you discuss at the 12:00 mark: I created an environment. Then I clicked the code view, on the right where your screen shows Releases, Packages, and Environments mine shows Releases, Packages, and Languages. I did not actually build and deploy to the Environment, I simply created and configured one Environment. Could that be why? Maybe a build and deployment is required? Thanks for any info.
That's correct, it won't show unless there been a deployment activity on that environment
Hey liked the video a lot and left a like. These new features sound like they would definitely help an agile team. But quick question. How does environment protection work with mid + sized team if you have multiple developers working on different tasks in the same repo? Lets say dev one checks in code and is waiting approval and while waiting dev 2 checks in his code and is then awaiting approval as well. What is the behavior of Github Actions pipeline in this state?
If a deployment A is waiting for approval in an environment, and another deployment B is queued for the same environment you''ll have it both waiting for approval. Then it is a matter of which one you approve first. Anyway, the other will still be in waiting state until you either approve it or cancel it.
on settings on my project cannot found environement option
Is it a private repo? If so it is normal, environments are available only on public repos. If you want to have them on private repos you need to be on GitHub Enterprise 😕
@@CoderDave yep yep it s enable by default if using normal account but not free for organization :(
The Environment setting, in my case, only appears on the public repository. Is that your case?
Yes, that’s correct. I believe I mention this also in the video, Environments are available only for public repos. If you have GitHub Enterprise, then it’s available also on private repos.
@@CoderDave Yes, I did not notice when you comment. I re-watched the video. Thanks to and congrats on your work.
How do I disable email notification for the review deployments approval,as I donot need email notification, is there any settings to do this at organization level instead of manually unsubscribing it can we do it in settings?
I believe that, at least for now, it is not possible
Hey can u pls lemme know if we can modify
If a job is not approved within 30 days, the workflow run will be automatically canceled.
30days to lesser number and how?
Unfortunately at the moment it is not possible to change that value
for private repository what to do ?
Unfortunately, this is not available for private repos on either personal account or teams plan :( GitHub has decided to make this available on private repos only in the GitHub Enterprise Cloud (GHEC) :(
If you are on private repos but not on GHEC, then you'd need to use some kind of workaround
Would the environment variables deploy automatically to their servers?
Not sure what you mean. You still have the deployment steps for your environments/servers/targets in the workflow. The Environment section of the job specifications allows you to control things like environment-specific secrets, approvals, etc