Adding assets

Exercises/01-Create-Dockerfile.md

@@ -0,0 +1,88 @@
+# Create the dockerfile
+
+In this session, we are going to be deploying an application within a **Docker** container. Before we can deploy our app, we need to begin setting up a foundation to make changes to.
+
+## Exercise: Add Dockerfile
+
+1. Create a new branch called `Docker`
+1. In the root of the repository, create a new file named: `Dockerfile`
+1. Copy and paste the following code snippet into the new file:
+
+      > **:warning: NOTE:** Update the **orgname** and **reponame** variables to your organization and repository names.
+
+      ```Dockerfile
+      #########################################
+      #########################################
+      ### Dockerfile to run some Some Build ###
+      #########################################
+      #########################################
+
+      # This is a copy of the GitHub Action runner
+      FROM myoung34/github-runner:latest
+
+      #########################################
+      # Variables #
+      #########################################
+      ARG orgname="organization name"
+      ARG reponame="repository name"
+
+      #########################################
+      # Label the instance and set maintainer #
+      #########################################
+      LABEL com.github.actions.name="Some Image" \
+            com.github.actions.description="Its a build image" \
+            com.github.actions.icon="code" \
+            com.github.actions.color="red" \
+            maintainer="GitHub DevOps <[email protected]>" \
+            org.opencontainers.image.authors="GitHub DevOps <[email protected]>" \
+            org.opencontainers.image.url="https://github.com/${orgname}/${reponame}" \
+            org.opencontainers.image.source="https://github.com/${orgname}/${reponame}" \
+            org.opencontainers.image.documentation="https://github.com/${orgname}/${reponame}" \
+            org.opencontainers.image.vendor="GitHub" \
+            org.opencontainers.image.description="Its a build image"
+
+      ########################################
+      # Copy dependencies files to container #
+      ########################################
+      COPY dependencies/* /
+
+      # ################################
+      # # Installs python dependencies #
+      # ################################
+      # RUN pip3 install --no-cache-dir pipenv
+      # # Bug in hadolint thinks pipenv is pip
+      # # hadolint ignore=DL3042
+      # RUN pipenv install --clear --system
+
+      # ####################
+      # # Run NPM Installs #
+      # ####################
+      # RUN npm config set package-lock false \
+      # && npm config set loglevel error \
+      # && npm --no-cache install
+      # # Add node packages to path
+      # ENV PATH="/node_modules/.bin:${PATH}"
+
+      # ##############################
+      # # Installs ruby dependencies #
+      # ##############################
+      # RUN bundle install
+
+      ######################
+      # Make the directory #
+      ######################
+      RUN mkdir -p /action/lib
+
+      #############################
+      # Copy scripts to container #
+      #############################
+      COPY library /action/lib
+
+      ######################
+      # Set the entrypoint #
+      ######################
+      ENTRYPOINT ["/action/lib/entrypoint.sh"]
+      ```
+
+1. Commit the file.
+1. Open a pull request and merge the `Docker` branch into the `main` branch.

Exercises/02-Create-CI-Action.md

@@ -0,0 +1,113 @@
+# Creating basic CI Github Action
+
+This exercise will walk you through setting up *Continuous Integration* on your current repository.
+The objective of *Continuous Integration* is to achieve constant feedback on your changes to your code base and begin the process of testing and deploying your code base.
+
+**GitHub Actions** run off of workflow files that are managed and maintained in your repository. The first action we are going to "install" on our repository uses an open source Action called [Docker Build](https://github.com/docker/build-push-action). This action will try to build the current `Dockerfile` and see if it compiles successfully.
+
+## Step 1: Add a GitHub Action workflow file
+
+1. Create a new branch of code called `CI`
+1. Create a new file named `.github/workflows/ci.yml`
+1. Copy the code below to the newly created file:
+
+    ```yaml
+    ---
+    ########
+    ########
+    ## CI ##
+    ########
+    ########
+    name: Continuous Integration
+
+    #
+    # Documentation:
+    # https://help.github.com/en/articles/workflow-syntax-for-github-actions
+    #
+
+    #############################
+    # Start the job on all push #
+    #############################
+    # Don't need to run on push to master/main
+    on:
+      push:
+        branches-ignore:
+          - 'master'
+          - 'main'
+
+    ###############
+    # Set the Job #
+    ###############
+    jobs:
+      build:
+        # Name the Job
+        name: CI
+        # Set the agent to run on
+        runs-on: ubuntu-latest
+        ##################
+        # Load all steps #
+        ##################
+        steps:
+          ##########################
+          # Checkout the code base #
+          ##########################
+          - name: Checkout Code
+            uses: actions/checkout@v2
+
+          ########################
+          # Setup Docker build X #
+          ########################
+          - name: Setup BuildX
+            uses: docker/setup-buildx-action@v1
+
+          ##############################
+          # Build the docker container #
+          ##############################
+          - name: Build Docker container
+            uses: docker/build-push-action@v2
+            with:
+              context: .
+              file: ./Dockerfile
+              build-args: |
+                BUILD_DATE=${{ env.BUILD_DATE }}
+                BUILD_REVISION=${{ github.sha }}
+                BUILD_VERSION=${{ github.sha }}
+              push: false
+    ```
+
+1. Commit the file.
+
+This workflow file is set up to run when a push is made to branches in the repository, unless they are pushed to the `main` or `master` branch. This is controlled by this section of the code:
+
+```yaml
+    push:
+      branches-ignore:
+        - 'master'
+        - 'main'
+```
+
+When we push a change to a branch, the GitHub Action will clone the repository code base, and run the docker build against the changes.
+
+## Step 2: Running your GitHub Action
+
+1. Open a pull request with the `CI` branch into the `main` branch.
+
+    In the pull request, you will see the GitHub Actions job running and its results. You can review the logs of the run and the steps it took by clicking on **Details** next to the GitHub Action. You can experiment with this Action, but making additional updates to the code and committing it.
+
+1. Merge the pull request.
+
+## Step 3: Add branch protection rules
+
+The last two pull requests we created and merged, were able to be merged without a required review. While this might work for this training repository, it doesn't scale well in the real world with business critical systems. Through the use of protected branches, we can enforce required reviews on pull requests to specific branches on our repository.
+
+To protect our main branch and require at least one review and a passing test, perform the following:
+
+1. On GitHub, navigate to the main page of the repository.
+1. Under your repository name, click **Settings**.
+1. In the left menu, click **Branches**.
+1. Next to "Branch protection rules", click **Add rule**.
+1. Under "Branch name pattern", type `main`.
+1. Select the **Require pull request reviews before merging** checkbox.
+1. Select the **Require status checks to pass before merging** checkbox.
+1. Select the **Continuous Integration** checkbox in the Status checks found in the last week for this repository.
+1. Click **Save changes**.

Exercises/02.A-Create-QA-Branch.md

@@ -0,0 +1,22 @@
+# Creating additional protected branches
+
+Many companies follow different models of deployment and git flow. Some only require the simple **GitHub** flow, while others use a more legacy git flow.
+If you follow more of the [Git Flow](https://nvie.com/posts/a-successful-git-branching-model/), you will likely need to create additional protected branches like `DEV`, `QA`, or `PROD`.
+
+![gitflow](https://user-images.githubusercontent.com/38323656/102368103-1c69ed80-3f80-11eb-9353-586432ec0678.png)
+> An example workflow which adopts the Git Flow branching strategy
+
+Once you have set up those branch protections, you can then use them later on to help trigger additional workflows and flags.
+
+To protect our new branch(es) and require at least one review and a passing test, perform the following:
+
+1. On GitHub, navigate to the main page of the repository.
+1. Under your repository name, click **Settings**.
+1. In the left menu, click **Branches**.
+1. Next to "Branch protection rules", click **Add rule**.
+1. Under "Branch name pattern", type `DEV` or `QA` or `PROD`.
+1. Select the **Require pull request reviews before merging** checkbox.
+1. Select the **Require status checks to pass before merging** checkbox.
+1. Select the **Continuous Integration** checkbox in the Status checks found in the last week for this repository.
+1. Click **Save changes**.
+1. Repeat for all branches you wish to protect.

Exercises/02.B-Create-Context-Job.md

@@ -0,0 +1,60 @@
+# GitHub Context
+
+**GitHub Actions** store information about the job, environment, and other aspects of the jobs contexts.
+
+Once the job runs, you will be able to see all variables of the job, and what could be available to you.
+This is helpful to debug environments and see what variables are available to you.
+You could then copy this code into another running workflow and see the output that is generated by that job.
+
+1. Create a branch called `context-job`
+1. Create a file, `.github/workflows/context.yml`
+1. Copy the following code:
+
+    > **:warning: Note:** This job is primarily used for debugging, or helping the user to find variable information stored in a running job.
+
+    ```yaml
+    # This is a basic workflow to help you get started with Actions
+
+    name: Context Info
+
+    # Controls when the action will run.
+    on:
+      # Triggers the workflow on push or pull request events but only for the master branch
+      push:
+        branches-ignore: main
+
+    # A workflow run is made up of one or more jobs that can run sequentially or in parallel
+    jobs:
+      Context-Info:
+        # The type of runner that the job will run on
+        runs-on: ubuntu-latest
+
+        # Steps represent a sequence of tasks that will be executed as part of the job
+        steps:
+        - name: Dump GitHub context
+          env:
+            GITHUB_CONTEXT: ${{ toJson(github) }}
+          run: echo "$GITHUB_CONTEXT"
+        - name: Dump job context
+          env:
+            JOB_CONTEXT: ${{ toJson(job) }}
+          run: echo "$JOB_CONTEXT"
+        - name: Dump steps context
+          env:
+            STEPS_CONTEXT: ${{ toJson(steps) }}
+          run: echo "$STEPS_CONTEXT"
+        - name: Dump runner context
+          env:
+            RUNNER_CONTEXT: ${{ toJson(runner) }}
+          run: echo "$RUNNER_CONTEXT"
+        - name: Dump strategy context
+          env:
+            STRATEGY_CONTEXT: ${{ toJson(strategy) }}
+          run: echo "$STRATEGY_CONTEXT"
+        - name: Dump matrix context
+          env:
+            MATRIX_CONTEXT: ${{ toJson(matrix) }}
+          run: echo "$MATRIX_CONTEXT"
+    ```
+    
+1. Open a pull request and merge the `context-job` branch into the `main` branch.

Exercises/02.C-Create-Manual-Job.md

@@ -0,0 +1,41 @@
+# GitHub Manual Job
+
+**GitHub Actions** allows you to be able to run manual jobs and pass the job inputs.
+
+This allows the user to be able to set up jobs that run when they want to manually initiate them, and pass variables needed to complete the job.
+This gives the users more flexability on how they could semi-automate the deploy/release process.
+
+1. Create a branch called `manual-job`
+1. Create a file, `.github/workflows/manual-deployment.yml`
+1. Copy the following code:
+
+> **:warning: Note:** This job is primarily used for manual triggers.
+
+```yaml
+# This is a basic workflow to help you get started with Actions
+name: Manual Deployment
+
+# Set the job to run manually
+on:
+  workflow_dispatch:
+    # Set the input variables you want to pull in
+    inputs:
+      branch:
+        description: 'Branch to deploy'
+        required: true
+        default: 'Dev'
+      app_list:
+        description: 'Comma separated list of apps to deploy'
+        required: true
+        default: 'App1,App2'
+
+jobs:
+  Deploy_Apps:
+    runs-on: ubuntu-latest
+    steps:
+    - run: |
+        echo "Running deployment of branch ${{ github.event.inputs.branch }}!"
+        echo "- Deploying the following Apps: ${{ github.event.inputs.app_list }}!"
+```
+
+1. Open a pull request and merge the `manual-job` branch into the `main` branch.

Exercises/03-Create-Dependabot-Config.md

@@ -0,0 +1,60 @@
+# Configure Dependabot
+
+In this session, we are going to be deploying [Dependabot](https://dependabot.com/) to your **GitHub Actions**. This is a built in tool inside **GitHub** that will help validate your code is up to date and free of known CVE's.
+
+### Exercise: Add Dependabot config
+
+1. Create a new branch called `Dependabot`
+1. Go to your repository, click on **Settings**
+1. On the left sidebar, click on **Security & Analysis**
+1. Click **Enable** on `Dependabot Security Updates`
+1. In the repository, create a new file named: `.github/dependabot.yml`
+1. Copy and paste the following code snippet into the new file:
+
+    ```yaml
+    #################################
+    # GitHub Dependabot Config info #
+    #################################
+    version: 2
+    updates:
+      - package-ecosystem: github-actions
+        directory: "/"
+        schedule:
+          interval: daily
+        open-pull-requests-limit: 10
+
+      # Maintain dependencies for docker
+      - package-ecosystem: "docker"
+        directory: "/"
+        schedule:
+          interval: "daily"
+        open-pull-requests-limit: 10
+
+      # Maintain dependencies for python with pip
+      - package-ecosystem: "pip"
+        directory: "/dependencies"
+        schedule:
+          interval: "daily"
+        open-pull-requests-limit: 10
+
+      # Maintain dependencies for js with npm
+      - package-ecosystem: "npm"
+        directory: "/dependencies"
+        schedule:
+          interval: "daily"
+        open-pull-requests-limit: 10
+
+      # Maintain dependencies for ruby with bundler
+      - package-ecosystem: "bundler"
+        directory: "/dependencies"
+        schedule:
+          interval: "daily"
+        open-pull-requests-limit: 10
+    ```
+
+1. Commit the file.
+1. Open a pull request and merge the `Dependabot` branch into the `main` branch.
+
+## Links
+
+- [Dependabot configuration](https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates)