%% date:: [[2023-04-26]] parent:: %% # [[Continuous Improvement]] Continuous Improvement is a software engineering approach that involves automating parts of software development in an integrated way, reducing the need for manual intervention. Its goals are to lessen the time between committing code to deployment and build in software quality by incorporating testing for the new code. Continuous Improvement is sometimes called Continuous Integration / Continuous Delivery (CI/CD), Continuous Deployment, or Continuous Testing. These names stress its application to different parts of the software development process. ![[cicd.png]] [^acarer] ## Continuous all the things The term "continuous" is getting the same treatment as "[[X as code]]" where it's being applied to everything under the sun. In this section, I differentiate between the nuances of each thing it's been applied to. However, I do think the differences are mostly semantic, and it's more important for a team to all be on the same page about how they define their continuous processes rather than for them to be using the term with the correct nuances. ### Continuous Development and Integration In [[Software Development]], continuous improvement involves building a [[Minimum Viable Product|fully-integrated slice of work]] that prioritizes something that works end-to-end over feature or scope creep. Continuous integration involves front-end, back-end, and design teams to collaborate from the beginning. The opposite of continuous integration is [[Big Bang integration]], in which different teams work independently, and then attempt to make it integrate. Continuous Integration technically only talks about the part of the process where one person's changes are merged ("integrated") into the main body of work (such as a main branch in a code repository). As such, it doesn't explicitly cover the tasks after that, such as testing or deployment. Viktor Farcic points out that this is usually indicates that a project that practices continuous integration alone are likely to be employing some manual testing due to a lack of confidence in automated tests. [^farcic] ### Continuous Delivery Continuous Delivery is an extension of Continuous Integration [^farcic] where after changes are merged into the mainline (integration), a single manual decision is taken (usually by the business) as to whether or not to push the changes to production. From then on, however, the deployment is automated. ### Continuous Deployment Continuous Deployment is a further extension of Continuous Delivery and increases the degree of automation in the process. In Continuous Deployment, there is no manual decision to push something to production or not; instead, changes that go through the entire process (including testing) are automatically deployed to production. ### Continuous Testing Continuous testing is a term that has emerged as an alternative to both [[Shift-left testing]] and [[Shift-right testing]] as it emphasizes the cyclical nature of a [[Software Development Lifecycle|SDLC]] rather than a linear process. It stresses the importance of always testing, rather than just moving a linear testing phase to the left or right.  [^ashby] Viktor Farcic cautions against using the term "continuous testing" as a separate process or activity to Continuous Integration/Delivery/Deployment. [^farcic] His argument is that testing is included in all of these processes, and speaking of it as a separate process contradicts its "continuity" and instead reinforces team silos to form. However, I think this is mostly semantic. While I agree that continuous testing is really just one of many activities that are done in a Continuous Deployment environment, it can be useful to think of testing as a distinct discipline and tests as a distinct deliverable. Doing so brings focus to it in a way that might not happen if it were incorporated into other activities in the [[Software Development Lifecycle|SDLC]]. [[The Continuous Testing Snowball]] ### Continuous Improvement Personally, I prefer the term *Continuous Improvement* as a catch-all term for everything in the [[Software Development Lifecycle|SDLC]] and also for other industries. #### [[Continuous note-taking]] ## A CI framework A modern CI framework begins with a developer checking code into a repository, which would then automatically kick off functional tests of the application that determine whether or not that code will be allowed to proceed to the next step. Once functional tests are passed, the code could then be automatically deployed into production, with reports emailed out to relevant stakeholders. A natural extension of this would be to add in a load testing framework. After functional tests pass, the code could potentially be deployed to a staging or similar environment, where we can run our API load testing scripts to see if there have been any performance regression bugs introduced by the code. In this way, load testing could be an extra check before sending out code to production. This sort of CI framework is preferable to the traditional process, which involves many manual checks and potential bottlenecks as the code is passed among different teams (development to functional testers to nonfunctional testers, with DevOps engineers helping each team along the way). A good CI framework may take a little bit more time to set up in order to come up with the correct path, but it dramatically reduces the amount of time required and encourages a development practice that is iterative, quick, and truly [[Agile]]. #### Key Characteristics of a CI framework - Changes are merged into the mainline frequently. - Smaller, more frequent changes are preferable to larger, more complex ones that cannot be incrementally merged. - Automated tests are used to verify that the new changes don't break other functionality. - A "pipeline" is created that consists of automated tasks, including testing, to verify whether a change can be safely deployed. - Deployment happens automatically when all tests pass (the PR is "green"). ## CI/CD tools - [[Continuous load testing with Jenkins|Jenkins]] - [[CircleCI]] - [[GitHub Actions]] - [[ArgoCD]] - [[Spinnaker]] - [[Flux]] ## References [^ashby]: [Dan Ashby](https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/), via [Lisa Crispin on Mabl](https://www.mabl.com/blog/shift-left-shift-right-shifting-and-why) [^farcic]: Farcic, V. (2021). _Continuous integration, delivery, deployment, and testing explained_. From https://www.youtube.com/watch?v=0ivcSjpUzl4 [^acarer]: Acarer, C. (2020). *CI/CD - Continuous Integration, Continuous Delivery, and Continuous Deployment*. Retrieved on May 1, 2023 from https://cacarer.com/ci-cd-continuous-integration-continuous-delivery-and-continuous-deployment/.