CI/CD In 5 Minutes | Is It Worth The Hassle: Crash Course System Design #2
CI/CD In 5 Minutes | Is It Worth The Hassle: Crash Course System Design #2
To get better at system design, subscribe to our weekly newsletter: https://bit.ly/3tfAlYD
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.
Content
8.011 -> What is CI/CD?
9.251 -> How does it help us ship faster?
11.509 -> Is it worth the hassle?
13.083 -> Let’s take a look.
14.76 -> CI/CD, or Continuous Integration and
Continuous Delivery, automates the
19.62 -> software development process from the initial
code commit all the way through to deployment.
25.68 -> It eliminates much of the manual
human intervention traditionally
29.64 -> required to get new code to production.
32.94 -> The CI/CD process takes care of building,
testing, and deploying new code to production.
38.16 -> The promise is that it enables software teams
to deploy better-quality software faster.
44.82 -> This all sounds very good,
but does it work in real life?
48.84 -> The answer is - it depends.
51.24 -> Let’s break up CI/CD into their own
parts and discuss them separately.
55.26 -> CI is less controversial and more common.
58.08 -> In a nutshell, it is the practice
of using automation to enable
62.64 -> teams to merge code changes into the
shared repository early and often.
68.52 -> Each commit triggers an automated
workflow on a CI server that runs a
74.1 -> series of tasks to make sure the commit
is safe to merge into the main branch.
79.2 -> A good CI process relies on a set of good tests.
82.32 -> It is non-trivial to maintain a set of tests
with sufficient coverage that is not flakey.
89.34 -> High test coverage usually takes longer to
run. This impacts developer productivity.
94.38 -> It is a tough balancing act, but it
is worth the effort to get it right.
99.66 -> What are some common tools used in CI?
102.6 -> A good source code management
system is the foundation.
105.9 -> Github is a very popular example. It should
hold everything needed to build the software.
111 -> This includes source code, test scripts, and
scripts to build the software applications.
117.12 -> There are many tools to
manage the CI process itself.
120.3 -> Github Actions and Buildkite are
some modern examples. Jenkins,
125.52 -> CircleCI, and TravisCI are also common.
128.76 -> These tools manage the build and test tasks in CI.
133.02 -> There are many test tools for
writing and running tests.
136.2 -> These tools are usually
language and ecosystem specific.
140.46 -> For example, for JS, Jest is an example of
the unit testing framework, while playwright
147.42 -> and cypress are some common integration
testing frameworks for web applications.
153.78 -> The build tools are even more
diverse and ecosystem specific.
158.34 -> Gradle is a powerful build tool for Java.
161.64 -> The Javascript build ecosystem is fragmented and
hard to keep track of. Webpack is the standard,
168.18 -> but many new build tools claim to be much faster,
but they are not yet as extensible as webpack.
175.08 -> Now let’s examine the CD part of CI/CD.
178.56 -> CD is continuous deployment.
181.62 -> If we are being truthful, real
continuous deployment is hard.
185.34 -> They do exist, but the practice
is not as common as CI.
189.96 -> Many teams only practice CD on
the most basic types of systems.
194.4 -> These systems are usually stateless,
like the API or web server tiers.
200.22 -> With good production monitoring, these systems
could be deployed continuously with minimal risks.
206.16 -> They are stateless, and rollbacks
are usually quick and harmless.
210.78 -> It is also a common practice to wrap new
features in feature flags to separate
216.06 -> the deployment of the code from
the activation of the features.
219.78 -> This allows the team to quickly shut off new
223.02 -> features if they cause any issues
without requiring a full rollback.
227.58 -> Canary deployment is also a common practice for
products with hundreds of millions of users.
233.46 -> It deploys the new production code to a
tiny subset of the power users and staff
239.28 -> who both appreciate new features and
have the risk appetite to help catch
244.38 -> problems before the new code is deployed widely.
247.98 -> This allows the team to test the new
code in a real-world environment while
253.02 -> limiting the blast radius if something goes wrong.
256.38 -> These techniques work well
for simple stateless systems.
260.34 -> On the other hand, very few teams have
the resources or the convictions to
265.8 -> implement real continuous, hands-off
deployment on complex stateful systems
271.2 -> like database backend clusters or other types
of stateful systems like a websocket cluster.
278.46 -> Instead, these systems are
usually on a fixed deploy cadence.
282.72 -> The deployment process is
manual, risky and time consuming.
287.4 -> They require the care of a
dedicated platform team. It
291.12 -> is rare to see these systems deploy
fully continuously and automatically.
296.7 -> What are some tools that are used for CD?
299.58 -> The tools we mentioned earlier
like Github Actions, Buildkite,
303.42 -> and Jenkins are commonly used to handle CD tasks.
306.72 -> There are also infrastructure-specific
tools that make CD easier to maintain.
311.94 -> For example, on Kubernetes, ArgoCD is popular.
316.68 -> In conclusion, CI/CD is a powerful
software development practice that can
322.14 -> help teams ship better-quality software faster.
325.68 -> However, it's not a one-size-fits-all
solution and its implementation may
330.36 -> vary depending on the complexity of the system.
334.74 -> If you'd like to learn more about system design,
check out our books and weekly newsletter.
339.12 -> Please subscribe if you learned something new.
341.46 -> Thank you so much and we'll see you next time.
Source: https://www.youtube.com/watch?v=42UP1fxi2SY