![\"\"](\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/10\/cicd-1024x574.jpg\")
<\/figure>\n\n\n\nIf you\u2019re writing software, whether it be a website, an iPhone app, or a low-level library, your steps to production will look something like the below:<\/p>\n\n\n\n These steps mean different things to different projects, but every project will involve some form of writing code, testing, building, and deploying.<\/p>\n\n\n\n Continuous integration and continuous deployment (CI\/CD) introduces automation into the software process. Instead of manually running tests, building your software, and deploying it, CI\/CD automates these steps away. Continuous integration automatically builds and tests your software on a regular basis, while continuous deployment will automatically deploy it when certain conditions are met.<\/p>\n\n\n\n CI\/CD often integrates with version control software such as git, allowing you to trigger automated tests and software builds when you commit or create a pull request.<\/p>\n\n\n\n With a CI\/CD tool, your process looks like the following diagram:<\/p>\n\n\n\n To take an example, say you write some code and open a pull request on your repository. Your CI will pick up the new code, test it, and build it. Your CI tool might also show you the test and build status within your pull request. Once you are happy with the code, you will merge the pull request, and your CD tool will pick up the built software and deploy it.<\/p>\n\n\n\n There are lots of tools out there to implement CI\/CD including Jenkins<\/a>, Travis CI<\/a>, CircleCI<\/a>, TeamCity,<\/a> and many more. Choosing a tool should be done on a case-by-case basis and will depend on your project, your budget, the previous experience of your team members, and what other tooling you are already using.<\/p>\n\n\n\n Continuous integration (CI)<\/strong> is the automation of the test and build stages in the software lifecycle. A CI system will build your software and run your test suite on some kind of automated trigger. This trigger could be pushing code to a source control repository. For those of you who\u2019ve used GitHub\/GitLab, the usual example is that a CI system will run for every pull\/merge request.<\/p>\n\n\n\n Continuous deployment (CD)<\/strong> is the automation of the deployment stage. This could include copying a binary to a public download URL or copying the build artifacts to your production servers. With continuous deployment, every time a code change builds and passes tests, it gets deployed into production.<\/p>\n\n\n\n Continuous delivery (also CD!)<\/strong> is a subset of continuous deployment. While continuous deployment will automatically deploy when tests pass and the build succeeds, continuous delivery will deploy whenever you choose to deploy. This could either be a manual button press or a regular time period such as once a week.<\/p>\n\n\n\n It is possible for a team to use CI without using CD, however, it\u2019s considered best practice to use both where possible. Generally, teams will first adopt CI, and then once they have confidence in their tests, and CI system will adopt CD.<\/p>\n\n\n\n There are many advantages to using CI\/CD when creating software. It\u2019s considered good practice for good reason!<\/p>\n\n\n\n Humans aren\u2019t as reliable as machines. When people do things, especially boring things that we have to repeat, there\u2019s a good chance that we will make mistakes. When you\u2019re running complicated test, build, or deployment workflows, there are infinite things that could go wrong:<\/p>\n\n\n\n This list might seem long, but it\u2019s by no means exhaustive. People are infinitely creative, including in the problems we make.<\/p>\n\n\n\n Having an automated test suite that requires no effort to run encourages people to write more tests. When your software is covered by more tests, it\u2019s more likely that the tests catch any bugs that you introduce.<\/p>\n\n\n\n On top of this, being able to rely on automation to run your tests ensures that tests have been run! When tests have to be run manually, it\u2019s easy to forget to do it.<\/p>\n\n\n\n CI\/CD also makes your tests more visible, which can help to enforce a culture of testing in the team. When a team cares about testing, the software they produce tends to have fewer bugs.<\/p>\n\n\n\n Implementing CI\/CD on your software projects helps you ship software faster. There are a few mechanisms behind this.<\/p>\n\n\n\n The first is that CI\/CD increases your team\u2019s trust in the code you write. Seeing a green check mark next to changes that you make is reassuring and allows people to approve changes faster since they don\u2019t have to build and test the changes themselves.<\/p>\n\n\n\n Second, automated feedback is usually faster than manual feedback. Software engineers on your team have multiple hats to wear. They have to gather requirements, write code, and think about test cases, all alongside reviewing other engineers\u2019 code. Having CI automatically run your tests and build is like having an instant basic review every time you push to a branch. This can help catch early bugs and make it more likely that your code passes human review.<\/p>\n\n\n\n Finally, automated deployment processes are much faster and more reliable than manual processes. Traditionally, ops teams would deploy software to production environments using a lengthy manual process. An automated deployment process can be run in seconds\/minutes and completely remove the chance of human error.<\/p>\n\n\n\n For the majority of projects, CI\/CD is overwhelmingly<\/strong> a good thing. As with everything in life, however, there are tradeoffs to setting it up and it\u2019s important to consider them.<\/p>\n\n\n\n Everything has a cost, and CI\/CD is no exception. Even though many CI\/CD systems are open source and free for commercial use, setting up and maintaining the system brings other costs. For example:<\/p>\n\n\n\n These costs have to be factored into your decision of whether or not to run a CI\/CD system. When deciding whether CI\/CD is worth it for your use case, you should weigh these costs against the potential costs of a bug in production.<\/p>\n\n\n\n Tests that run automatically aren\u2019t guaranteed to be good tests or have good coverage of your code. Testing your code well should be a higher priority than implementing CI\/CD and often requires organizational solutions instead of technical solutions.<\/p>\n\n\n\n CI\/CD makes tests more useful by ensuring they gatekeep code changes, however, it doesn\u2019t replace having tests in the first place. Without a good test suite for your code, many of the benefits of CI\/CD don\u2019t apply any more.<\/p>\n\n\n\n The newer a codebase is, the more likely it is to undergo large changes. This could include things like rewriting the code in a new language, rewriting the public interface, or architectural changes such as moving between a single monolith and multiple microservices.<\/p>\n\n\n\n Radical changes often mean that your CI\/CD has to change since it\u2019s likely that your test and build process is also changing. This means increased overhead and development time. For a small startup that is likely to go through many of these changes in a short period of time, CI\/CD may be more trouble than it\u2019s worth in the early stages.<\/p>\n\n\n\n The counterpoint to this argument is that CI\/CD can increase trust when radical changes happen. If your codebase dramatically changes, but the integration tests are still passing, then you can be more confident that the code is still working as expected.<\/p>\n\n\n\n In this article, you learned:<\/p>\n\n\n\n CI\/CD is a fantastic tool that can dramatically increase the reliability of your project and the speed with which you can deliver new code.<\/p>\n\n\n\n Aviator automates tedious developer workflows by managing git Pull Requests (PRs) and continuous integration test (CI) runs to help your team avoid broken builds, streamline cumbersome merge processes, manage cross-PR dependencies, and handle flaky tests while maintaining their security compliance.<\/p>\n\n\n\n There are 4 key components to Aviator:<\/p>\n\n\n\n![\"steps](\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/10\/image-2.png\")
<\/figure>\n\n\n\n![\"automated](\"https:\/\/lh7-rt.googleusercontent.com\/docsz\/AD_4nXcifexr2l7_pb45bLFu3ovsL_yTvWdnjBGOCbvxmEIieqdQhX-7M70r4trUUvbwilvHqL8eLe0CY5wf9qiAVh8FDdMxDux8nyxn7AzsE7_KcatXXMmb5H4SRcL3sK-lXpX8X4HzaFQFf3sMweQ4ZyBq1hF-?key=YUz6huVSNxDLAWGjMDRvc-YK\")
![\"MergeQueue](\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-1024x264.png\")
<\/a><\/figure>\n\n\n\nWhat is the difference between continuous integration and continuous deployment (CI vs CD)?<\/h2>\n\n\n\n
Advantages of using CI\/CD<\/h2>\n\n\n\n
Remove human error<\/h3>\n\n\n\n
\n
Ship fewer bugs<\/h3>\n\n\n\n
Release more frequently<\/h3>\n\n\n\n
Does CI\/CD have disadvantages?<\/h2>\n\n\n\n
CI\/CD is an investment<\/h3>\n\n\n\n
\n
CI\/CD is not a substitute for having tests<\/h3>\n\n\n\n
CI\/CD increases friction for large changes<\/h3>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\n
Aviator<\/a>: Automate your cumbersome processes<\/h2>\n\n\n\n
![\"\"](\"https:\/\/blog.aviator.co\/wp-content\/uploads\/2022\/08\/blog-cta-1024x727.png\")
<\/a><\/figure>\n\n\n\n\n