Scribd
Upload
27 views

More Than A Process: The Practices

Continuous Integration (CI) is a software development practice that involves automatically building and testing code changes frequently, such as every code change committed. The key principles of CI include maintaining a single code repository, automating builds, making builds self-testing, ensuring every code commit can build on an integration machine, keeping builds fast, testing in the production environment, making builds easily accessible, and automating deployment. CI helps catch bugs early, reduce integration issues, and increase software quality and reliability.

Uploaded by

max
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
27 views

More Than A Process: The Practices

Continuous Integration (CI) is a software development practice that involves automatically building and testing code changes frequently, such as every code change committed. The key principles of CI include maintaining a single code repository, automating builds, making builds self-testing, ensuring every code commit can build on an integration machine, keeping builds fast, testing in the production environment, making builds easily accessible, and automating deployment. CI helps catch bugs early, reduce integration issues, and increase software quality and reliability.

Uploaded by

max
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

More than a process

Continuous Integration is backed by several important principles and


practices.

The practices
 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 version
 Everyone can see what’s happening 
 Automate deployment

How to do it
 Developers check out code into their private workspaces
 When done, commit the changes to the repository
 The CI server monitors the repository and checks out changes when
they occur
 The CI server builds the system and runs unit and integration tests
 The CI server releases deployable artefacts for testing
 The CI server assigns a build label to the version of the code it just
built
 The CI server informs the team of the successful build
 If the build or tests fail, the CI server alerts the team
 The team fixes the issue at the earliest opportunity
 Continue to continually integrate and test throughout the project

Team responsibilities
 Check in frequently
 Don’t check in broken code
 Don’t check in untested code
 Don’t check in when the build is broken
 Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams
effectively manage themselves, removing the need to enforce policies
from on high.

Continuous Deployment
Continuous Deployment is closely related to Continuous Integration and
refers to the release into production of software that passes the
automated tests.

"Essentially, it is the practice of releasing every good build to users” ,


explains Jez Humble, author of Continuous Delivery.

By adopting both Continuous Integration and Continuous Deployment,


you not only reduce risks and catch bugs quickly, but also move rapidly to
working software.

With low-risk releases, you can quickly adapt to business requirements


and user needs. This allows for greater collaboration between ops and
delivery, fueling real change in your organization, and turning your release
process into a business advantage.

You might also like