1
00:00:07,440 --> 00:00:11,750
After watching this video, you will be able
to describe a CI/CD pipeline,

2
00:00:11,750 --> 00:00:15,020
define continuous delivery,
list the five key principles of continuous

3
00:00:15,020 --> 00:00:18,080
delivery,
define continuous deployment, and

4
00:00:18,080 --> 00:00:24,250
describe how DevOps manages risk.
Martin Fowler defines Continuous Delivery

5
00:00:24,250 --> 00:00:29,020
as a software development discipline where
you build software in such a way that the

6
00:00:29,020 --> 00:00:31,540
software can be released to production at
any time.

7
00:00:32,372 --> 00:00:34,044
That’s easier said than done.

8
00:00:34,579 --> 00:00:38,840
Let’s start with what Fowler means by “In
order to be able to release to production

9
00:00:38,840 --> 00:00:40,140
at any time.”

10
00:00:40,140 --> 00:00:43,579
It means the master branch should always
be deployable.

11
00:00:43,579 --> 00:00:47,589
In order to do that you need to build and
test every change.

12
00:00:47,589 --> 00:00:51,399
Building and testing every change is
the definition of continuous integration,

13
00:00:51,399 --> 00:00:55,300
so continuous delivery requires continuous
integration.

14
00:00:55,300 --> 00:00:59,639
This may be why people simply say CI/CD like
it is one word, because you need continuous

15
00:00:59,639 --> 00:01:04,379
integration in place before you can implement
continuous delivery.

16
00:01:04,379 --> 00:01:07,280
You need a way to know if something will "break
the build.”

17
00:01:07,280 --> 00:01:11,640
One way to accomplish this is by delivering
every change to a production-like environment.

18
00:01:11,640 --> 00:01:15,460
It doesn’t have to be the actual production
environment, but it should be enough like

19
00:01:15,460 --> 00:01:20,980
it so that the same procedure can be used
to deploy to production.

20
00:01:20,980 --> 00:01:26,900
Along the way, there are automated gates that
create a pipeline of checks such as unit testing,

21
00:01:26,900 --> 00:01:30,980
integration testing, quality checks, vulnerability
scans, security tests.

22
00:01:30,980 --> 00:01:34,780
These tests ensure the quality of the code.

23
00:01:34,780 --> 00:01:38,060
When this is all set up we refer to it as
a CI/CD pipeline.

24
00:01:38,060 --> 00:01:42,670
Like a pipeline, it is a set of tools where
the output of one feeds the input of the other.

25
00:01:42,670 --> 00:01:45,620
Let’s talk about what is needed to set up
a CI/CD pipeline.

26
00:01:45,620 --> 00:01:50,940
To start off with, you need a code repository
to host and manage all your source code.

27
00:01:50,940 --> 00:01:54,570
That’s the starting point that initially
feeds the pipeline.

28
00:01:54,570 --> 00:01:57,870
Then you need a build server to build the
application from source code.

29
00:01:57,870 --> 00:02:03,590
Most cloud-based CI tools like Travis CI and
GitHub Actions provide this for you.

30
00:02:03,590 --> 00:02:08,600
Then you’ll need an integration server/orchestrator
to automate the build and run the quality and

31
00:02:08,600 --> 00:02:09,979
other tests.

32
00:02:09,979 --> 00:02:12,950
Most Cloud based CI/CD pipelines like
IBM Cloud Continuous

33
00:02:12,950 --> 00:02:16,251
Delivery will provide an orchestration capability
for you.

34
00:02:16,251 --> 00:02:22,310
You will also need an artifact repository
to store binaries, the artifacts of the application.

35
00:02:22,310 --> 00:02:27,700
This is where your Java jar files and war files,
Python wheels, Ruby gems, Docker images, or

36
00:02:27,700 --> 00:02:31,680
whatever compiled artifacts have been tested
and proven to work.

37
00:02:31,680 --> 00:02:36,260
Finally, you will need a tool for the automatic
configuration of your deployment environment.

38
00:02:36,260 --> 00:02:42,840
Again, most cloud-based CI/CD pipeline tools
will provide a way to automate your deployment.

39
00:02:42,840 --> 00:02:46,760
When we overlay Continuous Integration and
Continuous Delivery on top of the software

40
00:02:46,760 --> 00:02:52,271
development lifecycle, we can see that plan,
code, build, and test are part of continuous

41
00:02:52,271 --> 00:02:53,271
integration.

42
00:02:53,271 --> 00:02:58,270
And, release, deploy, and operate are part
of continuous delivery.

43
00:02:58,270 --> 00:03:03,130
These are the two cycles, CI and CD, that
feed each other.

44
00:03:03,130 --> 00:03:07,290
There are five key principles that are at
the heart of Continuous Delivery.

45
00:03:07,290 --> 00:03:09,590
The first is built in quality.

46
00:03:09,590 --> 00:03:13,959
The CI/CD pipeline comes into play here, because
it allows every code change to go through

47
00:03:13,959 --> 00:03:18,240
a set of rigorous checks to ensure high code
quality.

48
00:03:18,240 --> 00:03:20,960
The second principle is working in small
batches.

49
00:03:20,960 --> 00:03:26,000
Working in small batches is important because
smaller changes are easier to test and represent

50
00:03:26,000 --> 00:03:27,830
less risk of something getting broken.

51
00:03:27,830 --> 00:03:33,750
The third, is important to acknowledge that
computers are good at performing repetitive

52
00:03:33,750 --> 00:03:36,860
tasks, but people-- not so much.

53
00:03:36,860 --> 00:03:38,730
People are good at solving problems.

54
00:03:38,730 --> 00:03:42,990
It is best to automate the repetitive tasks
using computers and then leave the problem

55
00:03:42,990 --> 00:03:44,860
solving to the people.

56
00:03:44,860 --> 00:03:49,810
The fourth key principle is to relentlessly
pursue continuous improvement.

57
00:03:49,810 --> 00:03:52,050
We should always be looking for ways to improve.

58
00:03:52,050 --> 00:03:56,900
That means we need to measure, using
actionable measurements, and then take action

59
00:03:56,900 --> 00:03:59,690
when the measurement shows what we can improve.

60
00:03:59,690 --> 00:04:03,880
And then finally, the fifth principle is
that everyone is responsible.

61
00:04:03,880 --> 00:04:09,010
When a build is broken, it is everyone’s
responsibility to help fix the build.

62
00:04:09,010 --> 00:04:12,300
Broken builds hold back everyone from moving
forward.

63
00:04:12,300 --> 00:04:16,599
I wanted you to be aware of the term “continuous
deployment.”

64
00:04:16,599 --> 00:04:21,910
I wish they had called it “continuous release”
to distinguish it from the initials of continuous

65
00:04:21,910 --> 00:04:23,590
delivery.

66
00:04:23,590 --> 00:04:26,970
Continuous deployment is reserved for deploying
to production.

67
00:04:26,970 --> 00:04:30,720
You can see by this graphic how continuous
integration covers pushing code to version

68
00:04:30,720 --> 00:04:35,030
control and automating the build and testing
once it is integrated.

69
00:04:35,030 --> 00:04:39,410
Then continuous delivery takes over, using
the artifacts from the build, and automatically

70
00:04:39,410 --> 00:04:42,280
deploys them to some environment.

71
00:04:42,280 --> 00:04:49,220
When we use automation to deploy to production,
then it is referred to as continuous deployment.

72
00:04:49,220 --> 00:04:53,830
Right about now you might be thinking to yourself,
“All of this automation sounds risky.”

73
00:04:53,830 --> 00:04:56,280
How do you manage that risk?

74
00:04:56,280 --> 00:05:00,830
DevOps manages risk by increasing the rate
of change rather than avoiding change.

75
00:05:00,830 --> 00:05:04,830
It sounds counter intuitive, but here is how
it works.

76
00:05:04,830 --> 00:05:08,600
In DevOps, deployment is king, deployment
should be painless.

77
00:05:08,600 --> 00:05:10,930
You want to deploy early and often.

78
00:05:10,930 --> 00:05:13,120
The idea is to build up muscle memory.

79
00:05:13,120 --> 00:05:16,120
You deploy your code several times before
it goes to production.

80
00:05:16,120 --> 00:05:18,030
You deploy it to a development environment.

81
00:05:18,030 --> 00:05:19,840
You deploy it to a test environment.

82
00:05:19,840 --> 00:05:22,270
You deploy it to a staging environment.

83
00:05:22,270 --> 00:05:25,150
You might deploy it to a pre-production environment.

84
00:05:25,150 --> 00:05:29,810
Since these deployments are automated, by
the time you deploy it to production, you

85
00:05:29,810 --> 00:05:31,240
know that it works.

86
00:05:31,240 --> 00:05:36,870
It would be unusual for it not to work because
computers are really good at repetitive tasks.

87
00:05:36,870 --> 00:05:40,229
This is why you don’t want humans involved
doing manual steps.

88
00:05:40,229 --> 00:05:44,680
Once you automate deployment, the code is
going to go to production the same way every

89
00:05:44,680 --> 00:05:46,360
time.

90
00:05:46,360 --> 00:05:51,350
The second notion is that deployment is decoupled
from activation.

91
00:05:51,350 --> 00:05:55,760
This may sound strange, but you can deploy
code with something called a feature flag.

92
00:05:55,760 --> 00:05:59,960
Feature flags turn your code on and off without
having to redeploy.

93
00:05:59,960 --> 00:06:02,580
You can deploy a feature, turn it on, and
see how it works.

94
00:06:02,580 --> 00:06:04,950
If it is not working, turn it off.

95
00:06:04,950 --> 00:06:09,170
Or if it is not ready, turn it off until it
is ready, and then turn it on in production.

96
00:06:09,170 --> 00:06:14,740
Feature flags have become very popular for
decoupling deployment from activation.

97
00:06:14,740 --> 00:06:19,160
You can also do waves of activation using
blue-green deploys and canary testing.

98
00:06:19,160 --> 00:06:23,590
This is where you deploy a new feature but
only send 10% of your traffic to it and monitor

99
00:06:23,590 --> 00:06:25,160
if it is working properly.

100
00:06:25,160 --> 00:06:28,520
Then you can then gradually send a higher
and higher traffic percentages to the new

101
00:06:28,520 --> 00:06:32,834
version until you are happy that it is working
and then send 100% of the traffic.

102
00:06:33,218 --> 00:06:35,870
Or if it is not working properly, then roll it
back.

103
00:06:35,870 --> 00:06:40,490
This is also known as “zero down-time”
deployment because at no time do you have

104
00:06:40,490 --> 00:06:41,949
the system take an outage.

105
00:06:41,949 --> 00:06:42,949
Right?

106
00:06:42,949 --> 00:06:44,960
You don’t have to bring it down to deploy
new code.

107
00:06:44,960 --> 00:06:48,900
Finally, deployment is not a “one size fits
all.”

108
00:06:48,900 --> 00:06:52,479
You need to see what works for the product
you are building and for what your customer

109
00:06:52,479 --> 00:06:53,479
expects.

110
00:06:53,479 --> 00:06:57,979
There are many techniques that can be adopted
to fit continuous delivery into your business

111
00:06:57,979 --> 00:06:59,710
scenario.

112
00:06:59,710 --> 00:07:04,870
In this video, you learned that CI/CD pipeline
tools provide a way to automate deployment.

113
00:07:04,870 --> 00:07:09,240
Release, deploy, and operate are part of continuous
delivery.

114
00:07:09,240 --> 00:07:13,800
The five key principles of continuous delivery
have to do with quality, working in small

115
00:07:13,800 --> 00:07:19,419
batches, automation, continuous improvement,
and shared responsibility.

116
00:07:19,419 --> 00:07:23,580
Continuous deployment is when automation is
used to deploy to production.

117
00:07:23,580 --> 00:07:28,864
DevOps manages risk by increasing the rate
of change rather than avoiding it.