index.md (6119B)
1 --- 2 title: "Maintenance Matters: Continuous Integration" 3 date: 2022-08-26T00:00:00+00:00 4 draft: false 5 canonical_url: https://www.viget.com/articles/maintenance-matters-continuous-integration/ 6 --- 7 8 *This article is part of a series focusing on how developers can center 9 and streamline software maintenance. The other articles in the 10 Maintenance Matters series are: [Code 11 Coverage](https://www.viget.com/articles/maintenance-matters-code-coverage/), 12 [Documentation](https://www.viget.com/articles/maintenance-matters-documentation/), 13 [Default 14 Formatting](https://www.viget.com/articles/maintenance-matters-default-formatting/), [Building 15 Helpful 16 Logs](https://www.viget.com/articles/maintenance-matters-helpful-logs/), 17 [Timely 18 Upgrades](https://www.viget.com/articles/maintenance-matters-timely-upgrades/), 19 and [Code 20 Reviews](https://www.viget.com/articles/maintenance-matters-code-reviews/).* 21 22 As Annie said in her [intro 23 post](https://www.viget.com/articles/maintenance-matters/): 24 25 > There are many factors that go into a successful project, but in this 26 > series, we're focusing on the small things that developers usually 27 > have control over. Over the next few months, we'll be expanding on 28 > many of these in separate articles. 29 30 Today I'd like to talk to you about **Continuous Integration**, as I 31 feel strongly that it's something no software effort should be without. 32 Now, before we start, I should clarify: 33 [Wikipedia](https://en.wikipedia.org/wiki/Continuous_integration) 34 defines Continuous Integration as "the practice of merging all 35 developers' working copies to a shared mainline several times a day." 36 Maybe this was a revolutionary idea in 1991? I don't know, I was in 37 second grade. Nowadays, at least at Viget, the whole team frequently 38 merging their work into a common branch is the noncontroversial default. 39 40 For the purposes of this Maintenance Matters article, I'll be focused on 41 this aspect of CI: 42 43 > In addition to automated unit tests, organisations using CI typically 44 > use a build server to implement continuous processes of applying 45 > quality control in general -- small pieces of effort, applied 46 > frequently. 47 48 If you're not familiar with the concept, it's pretty simple: a typical 49 Viget dev project includes one or more [GitHub Action 50 Workflows](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) 51 that define a series of tasks that should run every time code is pushed 52 to the central repository. At a minimum, the workflow checks out the 53 code, installs the necessary dependencies, and runs the automated test 54 suite. In most cases, pushes to the `main` branch will trigger automatic 55 deployment to an internal QA environment (a process known as [continuous 56 deployment](https://en.wikipedia.org/wiki/Continuous_deployment)). If 57 any step fails (e.g. the tests don't pass or a dependency can't be 58 installed), the process aborts and the team gets notified. 59 60 CI is a very tactical, concrete thing you do, but more than that, it's a 61 mindset -- it's your team's values made concrete. It's one thing to say 62 "all projects must have 100% code coverage"; it's another thing entirely 63 to move your deploys into a CI task that only runs after the coverage 64 check, so that nothing can go live until it's fully tested. Continuous 65 Integration is code that improves the way you write code, and a 66 commitment to continuous improvement. 67 68 So what can you do with Continuous Integration? I've mentioned the two 69 primary tasks (running tests and automated deployment), but that's 70 really just the tip of the iceberg. You can also: 71 72 - Check code coverage 73 - Run linters (like `rubocop`, `eslint`, or `prettier`) to enforce 74 coding standards 75 - Scan for security issues with your dependencies 76 - Tag releases in Sentry (or your error tracking tool of choice) 77 - Deploy feature branches to 78 [Vercel](https://vercel.com/)/[Netlify](https://www.netlify.com/)/[Fly.io](https://fly.io/) 79 for easy previews during code review 80 - Build Docker images and push them to a registry 81 - Create release artifacts 82 83 Really, anything a computer can do, a CI runner can do: 84 85 - Send messages to Slack 86 - Spin up new servers as part of a blue/green deployment strategy 87 - Run your seed script, assert that every model has a valid record 88 - Grep your codebase for git conflict artifacts 89 - Assert that all images have been properly optimized 90 91 That's not to say you can't overdo it -- you can. It can take a long 92 time to configure, and workflows can take a long time to run as 93 codebases grow. It can cost a lot if you're running a lot of builds. It 94 can be error-prone, with issues that only occur in CI. And it can be 95 interpersonally fraught -- as I said, it's your team's values made 96 concrete, and sometimes getting that alignment is the hardest part. 97 98 Nevertheless, I consider some version of CI to be mandatory for any 99 software project. It should be part of initial project setup -- get 100 aligned with your team on what standards you want to enforce, choose 101 your CI tool, and get it configured ASAP, ideally before development 102 begins in earnest. It's much easier to stick with established, codified 103 standards than to come back and try to add them later. 104 105 As mentioned previously, we're big fans of GitHub Actions and its 106 seamless integration with the rest of our workflow. [Here's a good guide 107 for getting started](https://docs.github.com/en/actions/quickstart). 108 We've also used and enjoyed [CircleCI](https://circleci.com/), [GitLab 109 CI/CD](https://docs.gitlab.com/ee/ci/), and 110 [Jenkins](https://www.jenkins.io/). Ultimately, the tool doesn't matter 111 all that much provided it can reliably trigger jobs on push and report 112 failures, so find the one that works best for your team. 113 114 That's the what, why, and how of Continuous Integration. Of course, all 115 this is precipitated by having a high-functioning team. And there's no 116 [GitHub Action for 117 **that**](https://github.com/marketplace?type=actions&query=good+development+team), 118 unfortunately. 119 120 *The next article in this series is [Maintenance Matters: Code 121 Coverage.](https://www.viget.com/articles/maintenance-matters-code-coverage/)*