Cloud Kube | Build Pipeline Initialization

Now that we have a service we’re going to start building our pipeline so that as we add functionality to the application we can incorporate any build needs into the pipeline.

Initialize Github Actions

Create a new directory from the root of the project called .github/workflows/ create a file called features.yaml in that directory

add this code to features.yaml

name: Cloud Application Feature Branch Build

on:
  push:
    branches-ignore:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0  # Shallow clones should be disabled for a better relevancy of analysis

      - name: Set up JDK 11
        uses: actions/[email protected]
        with:
          java-version: '11'
          distribution: 'adopt'
          cache: maven

      - name: Build with Maven
        run: ./mvnw -B test

Here’s a quick breakdown on what we’re doing with this action definition:

• Execute this on every push except if the push is to master. This will build on every commit/push. We’re using this to tell us if we broke the build by either not compiling or tests not passing.
• Checkout our git repo
• Setup a build environment (ubuntu with java 11). Cache the maven dependencies so that we can reuse our maven repo between builds.
• Run the maven build with test.

Push it up to execute the build. You should be on the microservice_dev branch already (change to that branch if you need to).

$ git add .

$ git commit -m "build pipeline"
[microservice_dev 37843c6] build pipeline
 1 file changed, 24 insertions(+)
 create mode 100644 .github/workflows/features.yaml

$  git push --set-upstream origin microservice_dev
Enumerating objects: 31, done.
Counting objects: 100% (31/31), done.
Delta compression using up to 4 threads
Compressing objects: 100% (13/13), done.
Writing objects: 100% (20/20), 2.30 KiB | 1.15 MiB/s, done.
Total 20 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: 
remote: Create a pull request for 'microservice_dev' on GitHub by visiting:
remote:      https://github.com/bullyrooks/cloud_application/pull/new/microservice_dev
remote:
To github.com-bullyrook:bullyrooks/cloud_application.git
 * [new branch]      microservice_dev -> microservice_dev
Branch 'microservice_dev' set up to track remote branch 'microservice_dev' from 'origin'.

Now navigate to your project in github and click on the Actions tab

You should see your build running, if you click on the build job, you’ll see your actions being run. Eventually, it should succeed

Create the Main Build and Deploy

Copy your feature.yaml file into a new file in the same directory called main.yaml. Change the push branch configuration to look like this:

on:
  push:
    branches:
      - main

Now commit and push this change

$ git add .

$ git commit -m "main build"
[microservice_dev 6491da8] main build
 1 file changed, 24 insertions(+)
 create mode 100644 .github/workflows/main.yaml

$ git push
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 4 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 676 bytes | 676.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To github.com-bullyrook:bullyrooks/cloud_application.git
   82f4cb5..6491da8  microservice_dev -> microservice_dev

This will trigger a single build (because it’s a commit to a non main branch), but it shouldn’t trigger two builds.

Now lets merge microserivce_dev into main

$ git checkout main
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

$ git merge --squash microservice_dev
Updating 1a73461..6491da8
Fast-forward
Squash commit -- not updating HEAD
 .github/workflows/features.yaml                    | 24 +++++++++++
 .github/workflows/main.yaml                        | 24 +++++++++++
 .gitignore                                         |  3 +-
 .../controller/HelloWorldController.java           | 15 +++++++
 .../controller/dto/HelloWorldResponse.java         | 14 +++++++
 .../controller/HelloWorldControllerTest.java       | 46 ++++++++++++++++++++++
 6 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 .github/workflows/features.yaml
 create mode 100644 .github/workflows/main.yaml
 create mode 100644 src/main/java/com/bullyrooks/cloud_application/controller/HelloWorldController.java
 create mode 100644 src/main/java/com/bullyrooks/cloud_application/controller/dto/HelloWorldResponse.java
 create mode 100644 src/test/java/com/bullyrooks/cloud_application/controller/HelloWorldControllerTest.java

$ git commit -m "microservice endpoint and build pipeline"
[main cf0e328] microservice endpoint and build pipeline
 6 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 .github/workflows/features.yaml
 create mode 100644 .github/workflows/main.yaml
 create mode 100644 src/main/java/com/bullyrooks/cloud_application/controller/HelloWorldController.java
 create mode 100644 src/main/java/com/bullyrooks/cloud_application/controller/dto/HelloWorldResponse.java
 create mode 100644 src/test/java/com/bullyrooks/cloud_application/controller/HelloWorldControllerTest.java

$ git push
Enumerating objects: 35, done.
Counting objects: 100% (35/35), done.
Delta compression using up to 4 threads
Compressing objects: 100% (16/16), done.
Writing objects: 100% (24/24), 2.78 KiB | 950.00 KiB/s, done.
Total 24 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 2 local objects.
To github.com-bullyrook:bullyrooks/cloud_application.git
   1a73461..cf0e328  main -> main

Navigate back to github actions tab. You should see a single build being kicked off from the main branch.

Conclusion

This is a very important stage in our application lifecycle. We’re going to be building off of these two pipelines continually in the next stages of the course. It’s important to have a distinction between ‘feature’ branch and ‘main’ branch builds. If we were going to work in a team environment, we may have a code review and pull request process which might have different behavior (code coverage report, static code analysis report, etc…) than the main build and deploy pipeline (which might actually deploy our code into a production environment).

In the following steps, I’m going to be building docker images as part of my feature branch pipeline, so that I can pull an image down and deploy manually (or automatically) as part of ‘acceptance testing’. However, you may choose a different process. Having the flexibility to implement your own pipeline is important, but just as important is understanding how they work so that you actually understand the options and implement the process that works for you and your team.