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.<\/p>\n\n\n\n
Initialize Github Actions<\/h2>\n\n\n\n
Create a new directory from the root of the project called .github\/workflows\/ create a file called features.yaml in that directory<\/p>\n\n\n\n<\/figure>\n\n\n\n
add this code to features.yaml<\/p>\n\n\n\n
name: Cloud Application Feature Branch Build\n\non:\n push:\n branches-ignore:\n - main\n\njobs:\n build:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v2\n with:\n fetch-depth: 0 # Shallow clones should be disabled for a better relevancy of analysis\n\n - name: Set up JDK 11\n uses: actions\/setup-java@v2.3.1\n with:\n java-version: '11'\n distribution: 'adopt'\n cache: maven\n\n - name: Build with Maven\n run: .\/mvnw -B test<\/code><\/pre>\n\n\n\n
Here’s a quick breakdown on what we’re doing with this action definition:<\/p>\n\n\n\n
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.<\/li>
Checkout our git repo<\/li>
Setup a build environment (ubuntu with java 11). Cache the maven dependencies so that we can reuse our maven repo between builds.<\/li>
Run the maven build with test.<\/li><\/ul>\n\n\n\n
Push it up to execute the build. You should be on the microservice_dev branch already (change to that branch if you need to).<\/p>\n\n\n\n
$ git add .\n\n$ git commit -m \"build pipeline\"\n[microservice_dev 37843c6] build pipeline\n 1 file changed, 24 insertions(+)\n create mode 100644 .github\/workflows\/features.yaml\n\n$ git push --set-upstream origin microservice_dev\nEnumerating objects: 31, done.\nCounting objects: 100% (31\/31), done.\nDelta compression using up to 4 threads\nCompressing objects: 100% (13\/13), done.\nWriting objects: 100% (20\/20), 2.30 KiB | 1.15 MiB\/s, done.\nTotal 20 (delta 2), reused 0 (delta 0), pack-reused 0\nremote: Resolving deltas: 100% (2\/2), completed with 2 local objects.\nremote: \nremote: Create a pull request for 'microservice_dev' on GitHub by visiting:\nremote: https:\/\/github.com\/bullyrooks\/cloud_application\/pull\/new\/microservice_dev\nremote:\nTo github.com-bullyrook:bullyrooks\/cloud_application.git\n * [new branch] microservice_dev -> microservice_dev\nBranch 'microservice_dev' set up to track remote branch 'microservice_dev' from 'origin'.\n<\/code><\/pre>\n\n\n\n
Now navigate to your project in github and click on the Actions tab<\/p>\n\n\n\n<\/figure>\n\n\n\n
You should see your build running, if you click on the build job, you’ll see your actions being run. Eventually, it should succeed<\/p>\n\n\n\n<\/figure>\n\n\n\n
Create the Main Build and Deploy<\/h2>\n\n\n\n
Copy your feature.yaml<\/code> file into a new file in the same directory called main.yaml<\/code>. Change the push branch configuration to look like this:<\/p>\n\n\n\n
Navigate back to github actions tab. You should see a single build being kicked off from the main branch.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
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).<\/p>\n\n\n\n
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.<\/p>\n","protected":false},"excerpt":{"rendered":"
\nNow that we have a service we’re going to start building our…\n<\/div>\n
![\"\"](\"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/01\/image-14.png?resize=368%2C85&ssl=1\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/01\/image-15.png?resize=400%2C96&ssl=1\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/01\/image-16-1024x274.png?resize=960%2C257&ssl=1\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/bullyrooks.com\/wp-content\/uploads\/2022\/01\/image-17.png?resize=855%2C325&ssl=1\")
<\/figure>\n\n\n\n