Continuous Integration (CI) is followed as a
development practice wherein the developers are required to
integrate their code into a shared repository multiple times a day.
Each and every check-in is always verified by build process
(automatic). This allows the teams to detect problems at an early
stage.
Since you are integrating very frequently, there
is a less possibility of things going drastically wrong. Thus the
developers and the team can spend more time in developing the
features smartly rather than solving build issues.
Continuous Integration process is very simple..
If it is not implemented, the cost goes higher. If we do not follow
a continuous integration approach, we need to spend periods between
integrations. This also makes it exponentially more difficult to
find and fix the problems. This issue becomes critical at times and
can easily derail a project from the schedule, or even cause it to
fail altogether.
Continuous Integration comes up with multiple
benefits to our organization. These are listed below -
- No need
to indulge in long and tense integration processes.
- The
visibility increases which enables greater communication.
- Catch
the issues early and kill them in the bud.
- Spend
less time in debugging and more time in development.
- It gives
a confidence to the senior management about the product.
- We do
not need to wait to see if our code is going to work or not.
- It
reduces integration challenges, thus allows us to deliver software
more rapidly.
Continuous integration is more than a process. It
is supported by several important processes and principles and
practices. These practices are listed below -
- Maintain
a single source repository
- Automate
the build
- Make
your build self-testing
- Every
commit should build on an integration machine
- Keep the
build fast
- Test in
a clone of the production environment
- Make it
easy for anyone to get the latest executable
- Everyone
can see what is going on
-
Automated deployment
These practices can be achieved by taking the
following steps -
Developers check out code into their
private workspaces.
When done, the commit changes to the
repository.
The Continuous Integration server monitors the
repository and checks out changes when they occur.
- The
Continuous Integration server builds the system and runs unit and
integration tests.
- The
Continuous Integration server releases deployable artefacts for
testing.
- The
Continuous Integration server assigns a build label to the version
of the code it just built.
- The
Continuous Integration server informs the team of the successful
build.
- If the
build or tests fail, the Continuous Integration server alerts the
team.
- The team
fix the issue at the earliest opportunity.
- Continue
to continually integrate and test throughout the project.
The responsibilities of the development team
members are listed below -
Check in at a regular interval.
- Do not
check in broken or un-compiled code
- Do not
check in untested code
- Do not
check in when the build is broken
- Do not
go home after checking in until the system builds
Continuous Deployment is very closely associated
to Continuous Integration. It refers to the release of the software
to production which has passed the automated tests. The practice is
to release a good quality code to the end users. As explained by
Jez Humble, author of Continuous Delivery.
Using Continuous Integration and Continuous
Deployment not only reduces the risks and catches bugs quickly, but
also releases the working software very rapidly.
With risk free releases, you can quickly adapt
the new business requirements and the customer needs. This allows
for higher collaboration between the ops and delivery. Thus,
fuelling real change in the organisation, and converting your
release process into a business advantage.
