You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 1, 2022. It is now read-only.
We will be working with Continuous Delivery. We will...
4
-
- Create a workflow to deploy to staging based on a label
5
-
- Create a workflow to deploy to production based on merging to master
6
-
- Use AWS configuration
3
+
We'll learn how to create a workflow that enables Continuous Delivery. You'll:
4
+
- create a workflow to deploy to staging based on a label
5
+
- create a workflow to deploy to production based on merging to master
6
+
7
+
Before you start, you should be familiar with GitHub and Continuous Integration. If you aren't sure where to start, you may want to check out these two Learning Lab courses:
7
8
8
-
Before you start, you should...
9
9
-[Introduction to GitHub](https://lab.github.com/githubtraining/introduction-to-github)
10
10
-[Continuous Integration with GitHub Actions](https://lab.github.com/githubtraining/set-up-continuous-integration-with-github-actions)
11
11
12
12
### What is Continuous Delivery?
13
13
14
-
According to [continuousdelivery.com](https://continuousdelivery.com/),
14
+
[Martin Fowler](https://martinfowler.com/bliki/ContinuousDelivery.html) defined Continuous Delivery very simply in a 2013 post as follows:
15
15
16
-
> Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way.
16
+
> Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
17
17
18
18
A lot of things go into delivering "continuously". These things can range from culture and behavior to specific automation. In this course, we're going to focus on deployment automation.
19
19
20
+
### Kicking off deployments
21
+
22
+
Every deployment is kicked off by some trigger. Engineers at many companies, like at GitHub, typically use a ChatOps command as a trigger. The trigger itself isn't incredibly important. In our use case, we'll use labels. When someone applies a "stage" label to a pull request, that'll be our indicator that we'd like to deploy our application to a staging environment.
23
+
20
24
## Step 1: Configure a trigger based on labels
21
25
22
-
During the `on` step, we define what should cause this workflow to run. In this case, we want the workflow to run whenever a label is applied to the pull request.
26
+
In a GitHub Actions workflow, the `on` step defines what causes the workflow to run. In this case, we want the workflow to run whenever a label is applied to the pull request.
23
27
24
28
### :keyboard: Activity: Configure the workflow trigger based on an a label being added
GitHub Actions features powerful controls for when to execute jobs and the steps within them. One of these controls is `if`, which allows you run a job only when a specific condition is met. See [`jobs.<job_id>.if` in _Workflow syntax for GitHub Actions_](https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) for more information.
4
+
5
+
### Using information within GitHub
6
+
7
+
Workflows are part of the GitHub ecosystem, so each workflow run gives you access to a rich set of data that you can use to take fine-grained control.
8
+
9
+
We'd like to run our workflow on a specific label called **stage**, so we'll achieve this in a single line that packs a punch. We'll use:
10
+
-[`if:`](https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idif) is the conditional that will decide if the job will run
11
+
-[`contains()`](https://help.github.com/en/github/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#contains) is a function that allows us to determine if a value like say, a label named `"stage"`, is contained within a set of values like say, a label array `["bug", "stage", "feature request"]`
12
+
-`github.event.pull_request.labels` is specifically accessing the set of labels that triggered the workflow to run. It does this by accessing the [`github` object](https://help.github.com/en/github/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#github-context), and the [`pull_request` event](https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows#pull-request-event-pull_request) that triggered the workflow.
13
+
-`github.event.pull_request.labels.*.name` uses [object filters](https://help.github.com/en/github/automating-your-workflow-with-github-actions/contexts-and-expression-syntax-for-github-actions#github-context) to filter out all information about the labels, like their color or description, and lets us focus on just the label names.
14
+
15
+
## Step 2: Trigger a job on specific labels
16
+
17
+
Let's put all this together to run our job only when a labeled named "stage" is applied to the pull request.
18
+
19
+
### :keyboard: Activity: Choose the Ubuntu environment for our app
Copy file name to clipboardExpand all lines: responses/03_workflow-steps.md
+34-6Lines changed: 34 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,15 +1,43 @@
1
1
# Workflow steps
2
2
3
-
So far, the workflow knows what the trigger is and what environment to run in. But, what exactly is supposed to run? The "steps" section of this workflow specify what actions to be run in the Ubuntu environment when new labels are added.
3
+
So far, the workflow knows what the trigger is and what environment to run in. But, what exactly is supposed to run? The "steps" section of this workflow specifies actions and scripts to be run in the Ubuntu environment when new labels are added.
4
4
5
5
## Step 3: Write the steps for the staging workflow
6
6
7
-
We won't be going into detail on the steps of this workflow, but it would be a good idea to check them out. You'll see that we're adding steps using existing actions for:
7
+
We won't be going into detail on the steps of this workflow, but it would be a good idea to become familiar with the actions we're using. They are:
### :keyboard: Activity: Write the steps for the staging deployment workflow
14
+
The course [_Using GitHub Actions for CI_](https://lab.github.com/githubtraining/using-github-actions-for-ci) also teaches how to use most of these actions in details.
15
+
16
+
### :keyboard: Activity: Deploy a Node.js app to AWS for the first time
17
+
18
+
1. In a new tab, [create an AWS account](https://portal.aws.amazon.com/billing/signup) if you don't already have one.
19
+
> Note: You may need a credit card to create an AWS account. If you're a student, you may also be able to take advantage of the [Student Developer Pack](https://education.github.com/pack) for access to AWS. If you'd like to continue with the course without an AWS account, Learning Lab will still respond, but none of the deployments will work.
20
+
1.**[Add a user](https://console.aws.amazon.com/iam/home?#/users$new?step=details)** in the IAM service with administrator permission.
21
+
- For detailed instructions on adding users, see [_Creating an IAM User in Your AWS Account_](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html) in the AWS docs.
22
+
1. In the confirmation screen, copy both the **Access key ID** and the **Secret access key** to a safe space. We'll use these in the next few steps as follows:
23
+
- Access key ID ➡️ `AWS_ACCESS_KEY`
24
+
- Secret access key ️️️ ➡️ `AWS_SECRET_KEY`
25
+
1. Back on GitHub, click on this repository's **[Secrets]({{ repoUrl }}/settings/secrets)** in the Settings tab.
26
+
1. Click **Add a new secret**
27
+
1. Name your new secret **AWS_ACCESS_KEY** and paste the value from the Access key ID generated on AWS.
28
+
1. Click **Add secret**.
29
+
1. Click **Add a new secret** again.
30
+
1. Name the second secret **AWS_SECRET_KEY** and paste the value from the Secret access key generated on AWS.
31
+
1. Click **Add secret**
32
+
1. Back in this pull request, edit the `.github/workflows/staging-workflow.yml` file to use a new action
33
+
```yml
34
+
- name: Deploy to AWS
35
+
uses: github/deploy-nodejs@master
36
+
env:
37
+
AWS_ACCESS_KEY: {% raw %}${{ secrets.AWS_ACCESS_KEY }}{% endraw %}
38
+
AWS_SECRET_KEY: {% raw %}${{ secrets.AWS_SECRET_KEY }}{% endraw %}
39
+
```
40
+
If you'd like to copy the full workflow file, it should look like this:
13
41
14
42
```yml
15
43
name: Staging deployment
@@ -50,7 +78,7 @@ jobs:
50
78
path: public
51
79
52
80
- name: Deploy to AWS
53
-
uses: docker://admiralawkbar/aws-nodejs:latest
81
+
uses: github/deploy-nodejs@master
54
82
env:
55
83
AWS_ACCESS_KEY: {% raw %}${{ secrets.AWS_ACCESS_KEY }}{% endraw %}
56
84
AWS_SECRET_KEY: {% raw %}${{ secrets.AWS_SECRET_KEY }}{% endraw %}
GitHub Actions is cloud agnostic, so any cloud will work. We'll show how to deploy to AWS in this course.
4
4
5
5
### S3 Buckets
6
6
7
-
Amazon S3 Buckets are containers. They're also a very flexible type of data storage- they can be configured to work in many different types of ways. They're popular for their security, scalability, and dependability. Our S3 Bucket will be the container that our application is deployed in, both in staging and in production.
7
+
Amazon S3 Buckets are a very flexible type of data storage -- they can be configured to work in many different types of ways. They're popular for their security, scalability, and dependability. Our S3 Bucket will store our application, both in staging and in production.
8
8
9
9
## Step 5: Confirm AWS S3 configuration
10
10
11
-
### :keyboard: Activity: Create an AWS account by the following specifications, and confirm here
11
+
### :keyboard: Activity: Create an S3 bucket
12
12
13
-
1. Create an account at [aws.amazon.com](https://aws.amazon.com/)
14
-
-_This requires credit card information. If you'd like to continue with the course without an AWS account, Learning Lab will still respond, but none of the deployments will work._
15
-
2.[Create an S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)
16
-
- If you aren't sure how to get there, you can search for `S3`.
17
-
- Name the bucket `github-sam-test`
18
-
- The region needs to be the same as what is specified in the `aws-config.yml` file in this pull request. :eyes:**For this exercise, choose us-west-2**. :eyes: If you'd like to choose another region, make sure to update the `aws-config.yml` file to match.
19
-
- For all other options, accept the defaults.
20
-
3. Confirm that you've created an S3 bucket by commenting anything in this pull request
13
+
1. Navigate to the [Amazon S3](https://s3.console.aws.amazon.com/s3/home) service and click on **Create bucket**.
14
+
- See [_Create a Bucket_](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) on AWS documentation for the most detailed instructions.
15
+
1. Name the bucket whatever you'd like, and jot the name down
16
+
1. Select a region, and jot it down. You'll need it later. These examples use **US West (Oregon)**, also known as **us-west-2**. If you'd like to choose another region, make sure to update the `aws-config.yml` file to match.
17
+
1. For all other options, accept the defaults.
18
+
1. In `.github/aws-config.yml` on this branch, change the value of `s3_bucket:` to match your chosen bucket name.
19
+
1. In the same file, confirm that the `region:` value matches your chosen region for the S3 bucket.
20
+
1. Commit your changes.
21
+
22
+
I'll respond when I detect a commit on this branch.
Copy file name to clipboardExpand all lines: responses/07_approve.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,9 @@ Whenever you're using a GitHub Action, it's important to read the documentation.
12
12
13
13
This file is a bit trickier. The template `aws-config.yml` file that was documented with the action has a placeholder for this template, but doesn't specify what we should do.
14
14
15
-
In our case, we created the `sam-template.yml` for you. It contains information that's specific about the application source code in this repository. When we tell AWS to deploy, it wonders "Deploy _what_?". This file communicates which files should be deployed, and how, within our S3 bucket on AWS.
15
+
This file is specific to deploying a serverless application to AWS. Specifically, an AWS SAM template tells AWS how to set up the application's architecture. Read more about it in [_AWS SAM Template Concepts_](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-template-basics.html) in the AWS documentation.
16
+
17
+
In our case, we created the `sam-template.yml` for you. It contains information that's specific about the application's endpoints and structure.
0 commit comments