Continuous Integration is Not Optional
Tags: webdev, github, testing, googlecloud
Published: 2021-03-30 04:24:01

<div class="modal-body">
<h4><strong>Stop Wasting Time On The Boring&nbsp;Stuff</strong></h4>
<p>With any project, there are the boring maintenance tasks that tend to take up more time than anyone would like them to. Need to do a new build of your game in Unity? Depending on the size of your game, that task could take awhile to build and deploy to the proper place. Want to push a new version of your website and run tests to make sure everything still works? Deploying the files to the appropriate place can take a minute and manual testing is often repetitive and error prone. Because of this, there are continuous integration (CI) tools that aim to automate a portion of your project lifecycle. I thought I would go through my favorites:</p>
<h3>Team City</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Z3aW3ie0E24XqLu2cHrXfw.png"><figcaption>Team City Development Chain. Source:&nbsp;<a href="https://www.jetbrains.com/teamcity/">TeamCity</a></figcaption></figure><p><a href="https://www.jetbrains.com/teamcity/">TeamCity CI/CD </a>gives you the ability to automate pipelines of varying complexity and scale with relative ease. This is mostly due to the build chains that let you construct a visual pipeline of how the code will come together during the build. Even if the code is distributed across multiple repositories you can chain them together when running the build. Team City’s biggest differentiator is not their UI&nbsp;however.</p>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*mGrmWhTygNn7Vo_wVnlYyA.png"><figcaption>Kotlin CI Config Example Source:&nbsp;<a href="https://www.jetbrains.com/teamcity/">TeamCity</a></figcaption></figure><p>Their biggest draw is that you can set up your CI using <a href="https://kotlinlang.org/">Kotlin</a> instead of boring Yaml. Which honestly makes sense because JetBrains (who runs TeamCity) developed the programming language. I use TeamCity at my everyday job and I find it a useful tool when building my&nbsp;games.</p>
<h3><strong>Google Cloud&nbsp;Build</strong></h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1000/1*IrdudiD82oZ5UD9F3uTIjw.png"><figcaption>Source: <a href="https://medium.com/@alvaroviebrantz?source=post_page-----d5e1cda504bf--------------------------------">Alvaro Viebrantz</a></figcaption></figure><p>As a part of the good cloud suite of offerings, <a href="https://cloud.google.com/docs/ci-cd">Cloud Build</a> is a relatively straightforward offering for continuous integration and continuous delivery solution. Integrating the CI pipeline into your project is a straightforward process of using Google Cloud and configuring your project. The basics are that you need to create a cloudbuild.yaml file (or even a JSON file) that lives in your project’s root directory that defines the steps needed to build your app/game/website. Here is an example of the same yaml command, done slightly differently so that it is super confusing.</p>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/700/0*oXvcKxblI3cn1km8"><figcaption>Source: <a href="https://dev.to/ceoshikhar/enhance-your-code-reading-experience-on-github-with-this-chrome-extension-24ei">Dave&nbsp;Stanke</a></figcaption></figure><p>Overall Cloud Build is an excellent Continuous Integration tool that allows you to simplify your build, release, and testing process. I actually use Google Cloud Build as apart of my CI process for deploying <a href="https://www.josephamaurer.com/">my website</a>. I have a trigger set up so that when I push to my Github repository, an action is triggered that grabs the updated code and merges it with the live branch of my website. It also takes care of producing artifacts such as a Docker container for testing. The best part is that it’s free! I highly recommend checking out <a href="https://medium.com/google-cloud/serverless-continuous-integration-and-ota-update-flow-using-google-cloud-build-and-arduino-d5e1cda504bf">Alvaro’s blog post</a> about how he uses CI to integrate with IoT&nbsp;devices.</p>
<h3><strong>Github Actions</strong></h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*_4Ex1uUhL93a3bHyC-TgPg.png"><figcaption>Source: <a href="https://github.com/features/actions">GitHub</a></figcaption></figure><p>Honestly, <a href="https://docs.github.com/en/actions">GitHub Actions </a>work remarkably similar to the previous two products I’ve mentioned here. The big difference here is that if you are integrating directly with GitHub repository where your code is already probably checked in. Actions are event driven, meaning that you can trigger CI/CD when on, pull request, deployment, page build, release, and lots of other comment events that occur around your code base. The downside here is that you are stuck with Yaml files that are checked into your&nbsp;<em>.github/workflows</em> directory of your repository.</p>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*hRCleWQfrSys76KDHcJ0UA.png"><figcaption>Source: <a href="https://aws.amazon.com/blogs/containers/create-a-ci-cd-pipeline-for-amazon-ecs-with-github-actions-and-aws-codebuild-tests/">AWS</a></figcaption></figure><p>There are a ton of possibilities with these tools and they are extremely flexible by design. You can configure these systems to integrate with your situation and how you need to deliver your&nbsp;product.</p>
<p><a href="https://twitter.com/maurerpwer">Follow me on Twitter </a>for ideas on how you can use continuous integration in your project to save you&nbsp;time!</p>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=cb803733f59d" width="1" height="1" alt="">
</div>