CI/CD

CI/CD, or Continuous Integration and Continuous Delivery, automates the software development process from the initial code commit all the way through to deployment.

It eliminates much of the manual human intervention traditionally required to get new code to production.

This process takes care of building,testing, and deploying new code to production.

The promise is that it enables software teams to deploy better-quality software faster.

 

CI is less controversial and more common.
In a nutshell, it is the practice of using automation to enable teams to merge code changes into the shared repository early and often.

Each commit triggers an automated workflow on a CI server that runs a series of tasks to make sure the commit is safe to merge into the main branch.

A good CI process relies on a set of good tests.

It is non-trivial to maintain a set of tests with sufficient coverage that is not flakey.
(충분한 범위를 갖춘, 안정적이지 않은 테스트 집합을 유지하는 것은 쉽지 않습니다.)

High test coverage usually takes longer to run. This impacts developer productivity.

It is a tough balancing act, but it is worth the effort to get it right.

 

 

What are some common tools used in CI?

A good source code management system is the foundation.

Github is a very popular example. It should hold everything needed to build the software.

This includes source code, test scripts, and scripts to build the software applications.

Github Actions and BuildKite are some modern examples.

Jenkins,CircleCI, and TravisCI are also common.

These tools manage the build and test tasks in CI.

There are many test tools for writing and running tests.

 

 

CD is continuous deployment.

They do exist, but the practice is not as common as CI.

Many teams only practice CD on the most basic types of systems.

These systems are usually stateless, like the API or web server tiers. (stateless <-> Stateful,상태를 보존하지 않)

With good production monitoring, these systems could be deployed continuously with minimal risks.

They are stateless, and rollbacks are usually quick and harmless.

It is also a common practice to wrap new features in feature flags to separate the deployment of the code from the activation of the features.( 새로운 기능을 코드에 추가했을 때 그 기능을 사용자에게 바로 노출시키지 않고, 대신에 코드에는 추가되어 있지만 기능이 활성화되지 않은 상태로 남겨두는 것입니다. 그러면 플래그를 통해 필요한 시점에 기능을 활성화할 수 있습니다. 이렇게 하면 새로운 기능을 안정적으로 테스트하고 사용자에게 롤아웃하는 과정을 관리하기가 편리해집니다.)

This allows the team to quickly shut off new features if they cause any issues without requiring a full rollback.

 

What are some tools that are used for CD?

The tools we mentioned earlier like Github Actions, Buildkite, and Jenkins are commonly used to handle CD tasks.

There are also infrastructure-specific tools that make CD easier to maintain.

For example, on Kubernetes, Argo CD is popular.

 

Reference:

https://www.youtube.com/watch?v=42UP1fxi2SY