{"id":2898,"date":"2022-01-31T13:09:38","date_gmt":"2022-01-31T20:09:38","guid":{"rendered":"https:\/\/weeksclan.com\/?p=2898"},"modified":"2023-09-28T02:57:06","modified_gmt":"2023-09-28T08:57:06","slug":"an-introduction-to-continuous-integration-delivery","status":"publish","type":"post","link":"https:\/\/weeksclan.com\/?p=2898","title":{"rendered":"An Introduction to Continuous Integration, Delivery, and Deployment"},"content":{"rendered":"

Once a project has established a CI pipeline with automatic test coverage, it is a best practice to constantly develop and improve the test coverage. Each new feature coming down the CI pipeline should have an accompanying set of tests to assert that the new code is behaving as expected. CI functionality comes with a list of supportive technologies that may be learning curve investments for the team to undertake. These technologies are version control systems, hosting infrastructure, and orchestration technologies. An added benefit of this focus on testing is that business and development teams have extra incentive to clearly define objectives at the start of the lifecycle.<\/p>\n

\"continuous<\/p>\n

As illustrated in Figure 4, SAFe\u2019s CALMR approach to DevOps (center) enables continuous integration and several practice domains (inner rings). Each of the four activities (in green) is a collaborative effort that draws upon DevOps expertise from multiple disciplines to maximize delivery speed and quality. Developers can rapidly push changes and experiment with new feature ideas to help improve the user experience.<\/p>\n

Agile & DevOps<\/h2>\n

Thorough planning is essential so that the engineers can write the test cases to validate that the code meets these goals. Jenkins is an automated CI server written in Java and used for automating CI\/CD steps and reporting. The goal of the continuous delivery pipeline stage is to deploy new code with minimal continuous integration solutions<\/a> effort, but still allow a level of human oversight. Acceptance tests are one of the last types of tests that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user\u2019s perspective.<\/p>\n

The deployment phase is responsible for automatically launching and distributing the software artifact to end-users. At deployment time, the artifact has successfully passed the integration and delivery phases. This will happen through scripts or tools that automatically move the artifact to public servers or to another mechanism of distribution, like an app store. Without a robust CI pipeline, a disconnect between the engineering team and the rest of the organization can form.<\/p>\n

Example CI\/CD workflow<\/h2>\n

Extending the rapid testing to run time tests in an automated testing environment leads naturally towards continuous delivery. The delivery phase is responsible for packaging an artifact together to be delivered to end-users. This build phase is kept \u2018green,\u2019 which means that the artifact should be ready to deploy to users at any given time. This subset of tools can be used to perform code quality checks and syntax reviews before the code is committed and to perform unit testing after the codebase is compiled and the application is built. CI addresses this inefficiency in traditional development pipelines using automation to increase the frequency of merging and integration from weeks to days or even hours.<\/p>\n

\"continuous<\/p>\n

This means your team is responsible for configuring and managing the CI system on your own infrastructure. For example, if you have customer data privacy concerns to meet compliance standards, on-premises may be a requirement. Additionally, on-premises instances may offer deeper customization and configuration options.<\/p>\n

What is continuous deployment?<\/h2>\n

In 2010, Timothy Fitz published an article detailing how IMVU’s engineering team had built and been using the first practical CI system. While his post was originally met with scepticism, it quickly caught on and found widespread adoption[12] as part of the Lean software development methodology, also based on IMVU. At Atlassian, we strive to keep developers innovating and our code bases healthy.<\/p>\n

\"continuous<\/p>\n

To ensure that the primary code line (“main” in Git parlance) remains healthy, run the same level of continuous integration on all development and stable version branches as well. When the build passes on a branch, the team has the confidence to merge that code upstream. Despite these objections, helping software development teams implement
\ncontinuous integration should be the number one priority for any organization
\nwanting to start the journey to continuous delivery. A good way to
\nsolve this problem is to practice
\ntest-driven development
\n(TDD), in which developers write automated tests that initially fail, before
\nthey implement the code that makes the tests pass.<\/p>\n

Use CI as part of continuous delivery or continuous deployment<\/h2>\n

Introducing CI to the aforementioned scenario allows software developers to work independently on features in parallel. When they are ready to merge these features into the end product, they can do so independently and rapidly. CI is a valuable and well-established practice in modern, high performance software engineering organizations. The transition from traditional manual steps into CI processes requires a profound change in how software teams function together for many traditional software organizations.<\/p>\n