1
00:00:07,440 --> 00:00:10,480
After watching this video, you
will be able to describe Continuous

2
00:00:10,480 --> 00:00:14,400
Integration and Continuous Delivery,
explain the reason for using small batches

3
00:00:14,400 --> 00:00:18,240
in Continuous Integration, and describe
the benefits of Continuous Integration.

4
00:00:19,120 --> 00:00:24,320
People use the acronym CI/CD as if it is one
thing, but Continuous Integration and Continuous

5
00:00:24,320 --> 00:00:30,640
Delivery are two separate and distinct practices.
Continuous Integration (CI) is the process of

6
00:00:30,640 --> 00:00:35,680
continuously building, and testing, and integrating
every developer change into the master

7
00:00:35,680 --> 00:00:40,640
branch after a set of tests have passed.
The result is potentially deployable code.

8
00:00:41,280 --> 00:00:46,720
Continuous Delivery (CD) is a series of practices
designed to ensure that code can be rapidly and

9
00:00:46,720 --> 00:00:51,840
safely deployed to production by delivering
every change to a production-like environment.

10
00:00:51,840 --> 00:00:57,600
Notice that I said “production-like.” It doesn’t
have to be deployed into production and, in fact,

11
00:00:57,600 --> 00:01:02,160
many people reserve the term “Continuous
Deployment” for when you are deploying

12
00:01:02,160 --> 00:01:06,400
continuously into production. For Continuous
delivery you just have to deploy it somewhere

13
00:01:06,400 --> 00:01:10,240
like a development, test, staging environment
that mimics the production environment.

14
00:01:10,240 --> 00:01:14,560
For example, if the production environment
is containers running on Kubernetes,

15
00:01:14,560 --> 00:01:19,040
you should deploy to a development
environment in containers on Kubernetes.

16
00:01:20,080 --> 00:01:23,040
Let’s start by looking at how
traditional development is done.

17
00:01:23,920 --> 00:01:27,520
Developers work in long-lived
development branches.

18
00:01:27,520 --> 00:01:32,080
Typically, they do it this way because
older version control systems made a

19
00:01:32,080 --> 00:01:37,280
complete copy of code whenever you made a branch, so
making branches was very expensive.

20
00:01:37,280 --> 00:01:42,720
The cost causes people to resist making branches
and when they do, they don’t delete very them often.

21
00:01:43,440 --> 00:01:47,760
With modern version control systems,
like Git, this is no longer the case.

22
00:01:47,760 --> 00:01:51,840
But some development teams have
kept the traditional practice.

23
00:01:51,840 --> 00:01:55,200
These development branches are kept
separate from the release branches

24
00:01:55,200 --> 00:02:00,400
and, periodically, merged into a release
branch, but not without lots of breakage.

25
00:02:00,400 --> 00:02:04,480
This is because the amount of changes
made over a long period of time,

26
00:02:04,480 --> 00:02:10,240
make the branch more vulnerable to merge
conflicts. Builds are run periodically, sometimes

27
00:02:10,240 --> 00:02:14,800
nightly, on the release candidate branch.
Developers continue to add to the

28
00:02:14,800 --> 00:02:18,880
development branch, which drifts further
and further from the master release branch.

29
00:02:19,440 --> 00:02:24,080
In this scenario, it may take days to
merge the code to get it back working.

30
00:02:24,800 --> 00:02:29,280
In contrast, Continuous Integration is
a development practice that requires

31
00:02:29,280 --> 00:02:33,440
developers to frequently integrate
code into a shared repository,

32
00:02:33,440 --> 00:02:39,120
and by frequently, I mean daily, if possible.
This is accomplished by having developers work in

33
00:02:39,120 --> 00:02:44,800
short-lived feature branches that are merged
into the master once the feature is complete.

34
00:02:44,800 --> 00:02:47,920
This means you integrate each
feature as it is completed.

35
00:02:47,920 --> 00:02:51,440
You don’t wait until a long list of features
are complete before you integrate them.

36
00:02:52,320 --> 00:02:55,440
Each check-in is then
verified by automated testing

37
00:02:55,440 --> 00:02:59,520
and an automated build, allowing teams
to detect problems early and often.

38
00:03:00,080 --> 00:03:04,720
Once merged, the branch is then deleted, and
a new branch is created for the new feature.

39
00:03:06,000 --> 00:03:09,360
Working in small batches helps
accomplish Continuous Integration.

40
00:03:10,000 --> 00:03:14,560
By committing regularly, every developer
can reduce the number of conflicting changes

41
00:03:14,560 --> 00:03:19,360
because less time has passed between merges.
The more time that passes,

42
00:03:19,360 --> 00:03:23,440
the greater the risk of merge conflicts.
Working for a week on the code and then checking

43
00:03:23,440 --> 00:03:28,320
it all in at once increases the risk that the
new features will conflict with other features.

44
00:03:28,960 --> 00:03:32,160
These conflicts can be difficult
and time-consuming to resolve.

45
00:03:32,800 --> 00:03:37,040
Using pull requests allows team members to
communicate about the change they are making.

46
00:03:37,600 --> 00:03:43,280
Every pull request is an opportunity for a code
review, so that other developers review the code.

47
00:03:43,280 --> 00:03:47,040
This ensures that all of the code is
being looked at by more than one person

48
00:03:47,040 --> 00:03:52,720
and lowers the risk of something going wrong.
Committing all changes at least once a day,

49
00:03:52,720 --> 00:03:58,720
or once per feature build, is generally considered
part of a definition of Continuous Integration.

50
00:03:59,760 --> 00:04:04,000
Speaking of pull requests, every pull
request should be built and tested.

51
00:04:04,000 --> 00:04:07,120
This should happen automatically.
The system should build the changes

52
00:04:07,120 --> 00:04:12,000
of the current working version to verify
that the integration works correctly.

53
00:04:12,560 --> 00:04:16,880
A common practice is to use automation,
in which a CI tool monitors

54
00:04:16,880 --> 00:04:21,120
the version control system and
then automates and runs the build automatically.

55
00:04:21,120 --> 00:04:26,640
Most CI tools like Travis CI, Circle CI, Jenkins,
GitHub Actions have the capability to monitor

56
00:04:26,640 --> 00:04:30,480
your version control system for changes
as well as automate the build process.

57
00:04:31,040 --> 00:04:34,400
Once the code is built, all tests
should be run to confirm the code

58
00:04:34,400 --> 00:04:39,120
behaves the way the developer expected it to.
In other words, make the build self-testing.

59
00:04:39,760 --> 00:04:43,840
The test results should feed back to
the pull request, and you should never

60
00:04:43,840 --> 00:04:50,000
merge a pull request that has failing tests.
One of the benefits of practicing Continuous

61
00:04:50,000 --> 00:04:55,120
Integration is that you can get faster reaction
time to the changes and you can move faster.

62
00:04:55,120 --> 00:04:57,920
You can move faster because
your tests are automated.

63
00:04:57,920 --> 00:05:01,440
Since the tests are automated you know
that everything you have done up to that

64
00:05:01,440 --> 00:05:06,640
point has been tested and known to work.
If you have these tests run automatically,

65
00:05:06,640 --> 00:05:10,560
you’re not wasting time testing; you’re
spending your time building features.

66
00:05:11,600 --> 00:05:16,640
CI reduces the risk of integrating code
because you are integrating smaller changes.

67
00:05:16,640 --> 00:05:20,720
When things change less, there is
less risk of breakage due to changes.

68
00:05:20,720 --> 00:05:26,000
Submitting pull requests puts more eyes on the
code and therefore results in higher code quality.

69
00:05:26,000 --> 00:05:31,440
Everyone has input on the quality of the code.
Finally, you know that the code that is in version

70
00:05:31,440 --> 00:05:33,120
control works.
Remember,

71
00:05:33,120 --> 00:05:39,289
the master branch should always be deployable.
I’ve had students ask me, “Can I write the test case

72
00:05:39,289 --> 00:05:42,880
after I build the user interface?”
And I tell them, that by that time it is too late.

73
00:05:42,880 --> 00:05:45,520
You have committed the user
interface to the master branch

74
00:05:45,520 --> 00:05:49,520
and if we need to deploy the master branch,
we have no idea if the user interface works.

75
00:05:50,320 --> 00:05:54,720
You should assume that code that
has not been tested does not work.

76
00:05:54,720 --> 00:05:58,400
You should never merge untested
code into the master branch.

77
00:05:58,400 --> 00:06:01,520
The master branch should always be deployable.

78
00:06:02,640 --> 00:06:06,560
In this video, you learned that
Continuous Integration is building,

79
00:06:06,560 --> 00:06:10,720
testing, and integrating every change into
the master branch after tests have passed.

80
00:06:11,520 --> 00:06:16,160
Continuous Delivery ensures that code can
be rapidly and safely deployed to production

81
00:06:16,160 --> 00:06:18,880
by delivering every change to
a production-like environment.

82
00:06:19,520 --> 00:06:23,440
Working in small batches aids
continuous integration by reducing

83
00:06:23,440 --> 00:06:27,760
the number of conflicting changes.
The benefits of Continuous Integration

84
00:06:27,760 --> 00:06:33,840
include faster reaction time, moving faster,
and reducing the risk of integrating code.