GitHub Actions: Approvals, Environments and Visualization DEEP DIVE

the day has come the features that everyone we're waiting for in github actions are finally here i'm talking about the new environments and manual approvals and today we're gonna take a look at how to enable them and how to use them properly this is gonna be fun hi everybody and welcome back to credit dave today we're going to talk about environments and manual approvals in github actions because those long-awaited features have been announced a couple of weeks ago during github universe 2020 and finally released just a few days ago on the 15th of december to be precise in this video we're gonna take a look and how to enable them and how to use them to control our release flow we can finally say that github actions has a strong ci cd capability if you want to have an overview of everything you can achieve with github actions i highly encourage you to check the other video i made on the subject after you're done with this one you can find the link up here and in the video description before we start i have a quick service notice i will not be posting a new 3-minute series video next friday because it's the 25th of december so just enjoy your christmas day if you celebrate it and i will see you the next tuesday also make sure to subscribe to this channel if you haven't already and if you want to learn more about devops especially with azure devops and github just click on the subscribe button below right now and turn on the notifications so you will not miss any new video so first off why do we talk about environments and manual approvals together well manual approvals is actually built on top of environments and they are just one of the features environments offer to prevent unauthorized deployments preserved secrets truck changes and much more for these reasons we will talk about all we can do with environments in this video but first let's see how to enable this feature just go to the repository settings and then you have this new environment section click on it and here you can create a new environment give it a name click on configure environment and here you have it to configure an environment in a user repository you must be the owner of that repo if you want instead to configure an environment in a repo that belongs to an organization then you will need to have the admin permissions also note that you will be able to configure and use the environments only in public repos or in repos that are part of a github enterprise cloud organization in fact environments and all their features including manual approvals are not supported on private repos outside of the enterprise cloud like in teams and pro plans in fact if you try to go to the settings of these plans you will simply not have the environment section right let's go and see what we have in the environment configuration all right here we are in the environments page and as you can see i have three environments configured development staging and production that we will use throughout this video let's take a look at production for example the first section we have over here is the environment protection rules currently we have two different rules one is for requiring reviewers that can be enabled or disabled and you can add up to six reviewers in this case i already have my name so if i want i can add anyone that has been added to this repo i can just search for the github handle and you can see that the person i wanna add is added to the list and if i click on it it's added to the required view list to be in the approvers list as i said you need to be part of the repo and you can configure so through the manage access tab but you only need read access to these repo and that allows you to have people who can approve deployments that don't necessarily have the ability to alter code and note here is that there are currently no way to specify a minimum number of reviewers meaning that just one person basically can approve the deployment but that may be a useful addition in the future next we have this wait timer and this is helpful with or without reviewers and allows you to basically delay the deployment of a number of minutes you find appropriate just click on it and then here you can specify the number of minutes that the job will wait since when it's triggered and that's basically it for the protection rules when you're done changing you can just save protection rules and as you can see over here the environment has been updated if we scroll a little bit down we can see we have the secret and in my case i have this subscription id secret github already has the secret management at the repo level but anybody with right access to a repo can alter those secrets or use them they cannot of course see them because as you probably know after saving a secret you can only update it or remove it but you cannot see their value but again we may not want all the contributors to have access to that section and this is the reason why we now have environment level secrets the job that does the deployment doesn't get access to these secrets until after the approval if any and these protect these secrets from unauthorized access and if we go to the secrets page we can also see another thing we have these repositories secrets and the environment and as you probably noticed i have the same secret or better a secret with the same name in both the environment section and the repository section in fact you can have secrets with the same name but remember that if an environment like in this case production has a secret with the same name of a repo secret the environment secret will override the ripple secret in jobs that target that environment and that environment only and this is very helpful for example in this case if you remember we have three environments and if i'm going to use the subscription underscore id secret in the jobs targeting those environments with this configuration dev and staging will use the repo level secret while only production will use the environment secret that was a lot of information before we move on and see how we can use all of that in a github actions workflow hit the like button below if you're enjoying this video or you find it insightful it will really help the channel growing and will mean a lot to me all right let's see how to use this as we've seen before i have three environments what i want to do in this example is deploying to the development environment only if i'm coming from a pull request while deploying to staging and then to production with an approval if i'm merging the code into main let's see how to configure that in our action workflow let's go to the action workflow and pick the right one so let's see what we have here first of all i have the build section which is of course common to all the different paths i just described and that does the compilation of course this is just a placeholder because i wanted to focus on the main structure of the workflow rather than on the single steps to deploy to dev as i said i want to do it only in case of pull request so i have this if clause over here which works on the event name and check if it's a pull request of course it depends on the build and they specify these new syntax for the environment as you can see the environment has two parameters one is the environment name and this should match the environment you created in the environment sections on the settings and then you can specify this url and this is a very cool thing because url can be either literal text like i have here let's say this is always my dev environment so i don't need to for example generate that automatically or can be retrieved from one of the steps contained in this deployed job if for example you have an arm deployment step that deploys to azure and automatically create a new service for your dam environment and that has a new url every time you can get that as an output parameter and put it here so that will be part of your environment and we will see in a second why this is useful if i scroll down we have the other two sections deploy to staging and deploy to prod and as i said before i want to deploy to staging only if i'm merging or committing into main and for this reason i have this other if over here which checks the ref and execute this stage only if we're going into main once again we depend on build and we have the environment section over here with staging environment and again a different url finally we have the deployment to production which depends on the deploy staging and so i don't need any other condition and once again we have the environment configuration section with the name and the url again also in those cases the url can be a literal string like here or from an output parameter of a step as you can see the configuration was super easy and using them it's even easier so let's make a change to the code base let's edit for example the readme file and let's commit this to a new branch committing to a new branch will allow me to open up a request and as usual as i do that the checks will start because the ci cd is configured to run and we can see now that this is being deployed to an environment and in fact it's already finished and we can see over here that we have this new box that also allow me to show the environment so i see that this is being deployed to development 15 seconds ago with these actions run if i click on view deployment i would be able to access the url we said before and if i click on the action run i can see the whole workflow as we have seen before here i have the build deployed to dev deploy to staging and deploy to production jobs but in this case they are visualized in a graphical way to better understand the flows and we see that after the build since we were coming from a pull request we didn't go to staging but we went in deployed to dev and here i also have the url from the deploy to dev job configuration and is the same url that i can access from the view deployment button in the environment within the pr super cool now let's go back and try to merge this pool request into the main branch if we now go back to our action we can see once again that the build is progressing and as soon as it finishes we should be able to see the deployment in staging and in fact here we have it the deployment staging has completed and so we have also the url and we now see that the workflow wants to deploy in production however since we set the approval request we need to have someone reviewing the deployment of course if you are on this screen already you have the review deployment button over here but you will also receive an email and a notification whenever a deployment that is assigned to you requires a review also soon the notifications will be integrated into the mobile app and even in slack and if we go back to our actions menu before approving this we can see we have this icon over here that informs us that his workflow is waiting for our review let's click on review deployments and here i can select the deployment i want to review in this case i only have this one i can leave a comment and i can either reject or like in this case i wanted to approve and deploy as soon as i do so if i don't have a wait time configured the new deployment job will be queued and executed accordingly and once again now it's completed and we do have the url showed here as well and this new screen doesn't only give you a much better way to visualize how your workflow is progressing but everything is audited in fact if i scroll down i can see who approved a deployment in which environment and if they've left a comment but doesn't stop here in fact i don't know if you've seen it before if we go back to our code page to the main page of our repo we have this environment section at the bottom of the page here we have the three environments and they are order by last activity the last one we've deployed to is production and this is why is on top now as i was saying before environments track the history of your deployments and so if we click on this we have the ability to see exactly what has been deployed to a specific environment and soon this will include work items issues and so on in the top part over here we can see the environments and the last deployment and if we scroll down we see the activity log of what happened in all the environments since they are being created this is super cool and gives you a lot of control over what's happening on your environments of course you can filter by environment and for each of the last deployments you can also check the view deployment which once again brings you to the url that is configured on your environment all right that's it for today as you have seen is very easy to configure and use environments and manual approvals with github actions and in my opinion they will open a new world of possibilities for cd and release control but let me know in the comment section below what you think about these features and how you plan to use them finally i want to wish every one of you merry christmas if you celebrate it this is longer you can find the link up here the link only on public pablo it will help the channel growing the channing what is the channeling it's pretty easy thanks so much for watching i really hope you enjoyed it hit the like button below subscribe if you haven't already and i see you in the next video here on coder dave

Channel: CoderDave

Views: 4,144

Rating: 4.9384613 out of 5

Keywords: github actions environments, CoderDave, github actions approvals environments and visualization deep dive, github actions approval, github actions manual approval, github actions workflow approval, github actions environment, github actions environment demo, github actions environment secrets, github actions visualization, github actions visual graph, github actions deep dive, how to configure an environment in github actions, how to approve a deploy in GitHub Actions, Github

Id: w_37LDOy4sI

Length: 13min 43sec (823 seconds)

Published: Mon Dec 21 2020