Main.ContinuousIntegration History
Hide minor edits - Show changes to output
Changed line 53 from:
* [[http://jenkins-ci.org/|Jenkins]] : the most popular CI software that have a huge number of plugins.
to:
* [[http://jenkins-ci.org/|Jenkins]] : the most popular CI software with a huge number of plugins.
Changed line 29 from:
#Check-in regularly to mainline
to:
#'''Check-in regularly to mainline'''\\
Changed line 31 from:
#Have an automated test suite / use TDD
to:
#'''Have an automated test suite / use TDD'''\\
Changed line 33 from:
#Always run tests locally before committing
to:
#'''Always run tests locally before committing'''\\
Changed line 35 from:
#Don’t commit broken code to the mainline!
to:
#'''Don’t commit broken code to the mainline!'''\\
Changed line 37 from:
->2. Don’t check-in on a broken build
to:
#'''Don’t check-in on a broken build'''\\
Changed line 39 from:
#Fix broken build immediately
to:
#'''Fix broken build immediately'''\\
Changed line 41 from:
#Time-box fixing before reverting
to:
#'''Time-box fixing before reverting'''\\
Changed line 43 from:
#Never go home on a broken build
to:
#'''Never go home on a broken build'''\\
Changed line 45 from:
#Don’t comment out failing tests
to:
#'''Don’t comment out failing tests'''\\
Changed line 47 from:
#Keep your build fast
to:
#'''Keep your build fast'''\\
Changed lines 52-53 from:
* An excellent post from
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
to:
* An excellent post from [[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
Changed line 37 from:
to:
->2. Don’t check-in on a broken build
Changed line 52 from:
An excellent post from
to:
* An excellent post from
Changed lines 54-55 from:
[[http://jenkins-ci.org/|Jenkins]] : the most popular CI software that have a huge number of plugins.
to:
* [[http://jenkins-ci.org/|Jenkins]] : the most popular CI software that have a huge number of plugins.
Changed lines 3-4 from:
Continuous Integration (CI) is a software development pratice backed by a set of tools.
to:
Continuous Integration (CI) is a software development practice backed by a set of tools.
Changed lines 28-29 from:
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
to:
!!! Top 10 rules to apply continuous integration
#Check-in regularly to mainline
Continuous Integration is about integrating early and often. To take advantages of the CI methodology, you need to share your code with all developers in the mainline (core repository, trunk) quickly. It implies small tasks / increments.
#Have an automated test suite / use TDD
Each piece of code should come with its automated tests. A good practice is to write tests before the code: Test-Driven Development.
#Always run tests locally before committing
Yes, there is a server that runs test for you … but it does not prevent us to run a minimum set of tests in your development environment. The CI server is here to detect problems not seen in your development environment.
#Don’t commit broken code to the mainline!
A source code repository is not a disk backup. A (known) broken code should never be committed to the mainline.
#Don’t check-in on a broken build
If you commit on a broken build, you loose feedback on this integration. If there are several commits on a broken build, you may end with a lot of bugs introduced in the mainline and loose your time to track problems.
#Fix broken build immediately
Fix broken builds should be the highest priority of the team. It prevents other developers to check-in and will end with a big integration task. The solution is to time-box the fix.
#Time-box fixing before reverting
Define a reasonable time (for example 20 minutes) allowed to fix a broken build. Once this time elapsed, revert to the latest working version and take the time you need to fix it. Then commit again.
#Never go home on a broken build
We don’t want you to stay at work all the night! If you don’t have time, revert, go home, and fix it the next day.
#Don’t comment out failing tests
We don’t want broken builds but we need to be confident in our code robustness. We need all tests, more tests!
#Keep your build fast
The key is to get a rapid feedback. So, you need to get your build fast (ideally <10 min). If you cannot speed the build up, use a staged build.
!!!Some references
An excellent post from
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
[[http://jenkins-ci.org/|Jenkins]] : the most popular CI software that have a huge number of plugins.
#Check-in regularly to mainline
Continuous Integration is about integrating early and often. To take advantages of the CI methodology, you need to share your code with all developers in the mainline (core repository, trunk) quickly. It implies small tasks / increments.
#Have an automated test suite / use TDD
Each piece of code should come with its automated tests. A good practice is to write tests before the code: Test-Driven Development.
#Always run tests locally before committing
Yes, there is a server that runs test for you … but it does not prevent us to run a minimum set of tests in your development environment. The CI server is here to detect problems not seen in your development environment.
#Don’t commit broken code to the mainline!
A source code repository is not a disk backup. A (known) broken code should never be committed to the mainline.
#Don’t check-in on a broken build
If you commit on a broken build, you loose feedback on this integration. If there are several commits on a broken build, you may end with a lot of bugs introduced in the mainline and loose your time to track problems.
#Fix broken build immediately
Fix broken builds should be the highest priority of the team. It prevents other developers to check-in and will end with a big integration task. The solution is to time-box the fix.
#Time-box fixing before reverting
Define a reasonable time (for example 20 minutes) allowed to fix a broken build. Once this time elapsed, revert to the latest working version and take the time you need to fix it. Then commit again.
#Never go home on a broken build
We don’t want you to stay at work all the night! If you don’t have time, revert, go home, and fix it the next day.
#Don’t comment out failing tests
We don’t want broken builds but we need to be confident in our code robustness. We need all tests, more tests!
#Keep your build fast
The key is to get a rapid feedback. So, you need to get your build fast (ideally <10 min). If you cannot speed the build up, use a staged build.
!!!Some references
An excellent post from
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
[[http://jenkins-ci.org/|Jenkins]] : the most popular CI software that have a huge number of plugins.
Added line 21:
A classical continuous integration worflow is as follows:
Changed line 15 from:
to:
*and any relevant rules.
Added lines 6-15:
Quality checks need to provide more confidence that your software may be put into production. They can include :
* compiling the software (at the very minimum, it should compile),
* testing the software (all tests must pass),
* checking code conventions breaches,
* static analysis of the code
**find design violations,
**search for duplicated code,
**search overly complex code (cyclomatic complexity),
**and any relevant rules.
Added lines 10-15:
#A developer commits changes to the version control system (central repository).
#The repository, via a post-commit hook, tells the CI server a change has occurred.
#The CI server retrieves the latest sources from the central repository and then builds the software (build script is shipped with sources). This step is called integration.
#The CI server aggregate build results and generates a feedback. This feedback is often materialized by emails but it can also be instant messaging, tweets, a visual feedback on a screen or a red light in the dev room, etc.
Changed lines 3-4 from:
Continuous Integration (CI) is, first and foremorst, a process backed by a set of tools.
to:
Continuous Integration (CI) is a software development pratice backed by a set of tools.
Added lines 6-9:
It implies to publish often changes to the mainline of the central repository shared by all developers.
%center%Path:/demarey/pmwiki/images/ci-bigpicture.png"Continuous Integration big picture" | '''Figure 1 : Continuous Integration big picture'''
Changed lines 1-7 from:
!!What is Continuous Integration ?
to:
!!What is Continuous Integration?
Continuous Integration (CI) is, first and foremorst, a process backed by a set of tools.
It is best to think of continuous integration as a mindset that allows you to reduce risks by frequently integrating incremental software development changes. Risks are managed by discovering them earlier and by applying quality checks at each change.
Here is an excellent post from
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].
Continuous Integration (CI) is, first and foremorst, a process backed by a set of tools.
It is best to think of continuous integration as a mindset that allows you to reduce risks by frequently integrating incremental software development changes. Risks are managed by discovering them earlier and by applying quality checks at each change.
Here is an excellent post from
[[http://martinfowler.com/articles/continuousIntegration.html | Martin Fowler on Continuous Integration]].