Environments are used to describe a general deployment target like production, staging or development.
When a GitHub action workflow deploys to an environment, the environment is displayed on the main page
of the repository.
We can configure environments with protection, rules and secrets.
If workflow job that reference an environment must follow any protection rules for the environment before
running or accessing the environment.
Secrets.
Let's create an environment and explore this concept.
We can use an environment protection rule to require a manual approval.
Allow me to add a user account over here.
And now in order to run the workflow jobs that reference this environment.
GitHub will first seek the approval of a specific person or team specified over here.
We can list up to six users or themes as reviewers.
Moving on.
Another environmental protection rule can be used to add a wait time to delay a job for a specific amount
of time after the job is initially triggered.
We must specify a time in minutes and it can be any value between 0 to 43200, which is equal to 30
days.
So precisely, we can add a delay of up to 30 days before a workflow can actually use this environment
and start the deployment.
Right.
As you can rightly realize, this delay time can save you from the situations where or should I accidentally
click on this button?
I didn't really mean to run the workflow.
So if you have the delay time added, nothing will happen.
If you mistakenly click on the deployment or mistakenly push your code, it will wait for a certain
time and in that time you can always go and cancel the workflow if you did not intend to actually run
it.
I am keeping the wait time as one minute so that we do not have to wait a lot for this demonstration.
Okay, let's save the protection rule.
Moving on, we have explored GitHub repository secrets and how we can store the sensitive information
inside them and use the information inside GitHub action workflows.
While the repository secrets are very secure way of storing our sensitive information, there is one
problem associated with this.
The problem is that they are repository level secrets.
Please allow me to explain this.
We want consistency in our workflows, so we want to be able to use the same workflow for dev staging
and production involvement, let's say.
Now if you have a different password for your dev environment and production environment, how will
you store these passwords in these repository level secrets?
Obviously, to make it distinguish between dev and production, you have to append this environment
name inside secret name like this, isn't it?
With this you will have to have extra logic added in your GitHub workflows to take appropriate value
based on the environment in which we are deploying.
Right.
There are good chances that we will not be just dealing with one or two secrets.
There are going to be many secret values that we want to store.
So appending the environment name in the secret name and using this name inside workflow is going to
add a lot of confusion and going to make our workflow unreadable.
So it's not a clever idea at all, correct?
Well, solution to this problem is use GitHub environment secrets.
We can create the secrets over here.
Okay.
So we have configured our production environment.
We have these protection rules and one secret.
Now let's see how we make use of this environment in our GitHub workflow.
In order to use environment inside GitHub workflow, we just have to use these property environments
and specify the name of environment to which we want to deploy our workflow, right?
So right now we have this environment production.
So I specified its name over here.
Let's not worry about this URL property.
I've kept it over here just to show you how differently it will look inside GitHub workflow logs.
So we will see this in a moment.
Now inside our steps, we can use the secret value as usual repository secret.
We just have to specify secrets and then EP secret.
But this time instead of going to the repository secrets directly first it will check the value of the
secret in the environment that we have specified.
And if the secret value is found in the environment, it will take it from there.
If it is not found in the environment, then it will go ahead and take the value of the secret from
the repository level secret.
So right now I want this deployment job to reference this environment and proceed with the deployment.
Okay, so let me save the workflow and push it to the repository.
OC here is our workflow.
GitHub environments.
So let's run this.
We are too much used to seeing our workflow in running state as soon as we click on the run button.
But this time it didn't happen, right?
Why?
Because the environment that we have specified has a required reviewer protection rule.
Okay.
First of all, the party whose approval is asked in the Environment Protection Rule has to approve the
deployment.
In this case, it's me.
So I'll simply say this is approved.
Okay.
By the way, comment is not mandatory.
Okay.
And I'll say approve and deploy.
Apart from this approval, we also have a protection rule which is specified as valid for 2 minutes
before starting the deployment.
For this reason, the workflow is not yet triggered and it's waiting.
Once the wait time is complete, it will automatically trigger.
Five, four, three, two, one, go.
Okay.
So the deployment is started.
And it is completed pretty fast.
If we expand this print secret from involvement, we can see it was successfully able to fetch the value
from the environment secret that we created just a few minutes back.
How cool is that?
Okay.
The URL that we specified over here is displayed in the workflow run like this.
For now it is a dummy value.
But when we will be working with real dev and production environment there, we can specify the actual
URL like this.
Also, we can always go back in time and see who had approved a particular workflow by seeing the approvals
or here.
I hope now you are clear on this concept of GitHub environments.
Well, that's it for now.
Take good care of yourself.
Thank you.