Reference to Martin Fowler's great article Continuous Integration , I liked to summarize some of most important points in the article along with the main steps that a developer should follow in his daily process according to my understanding from the article
What is it?
software development practice where
members of a team integrate their work frequently (at least daily)
Benefits of CI:
1.
reduced risk (frequent tests
and integration for small changes)
2.
Have a predictiction how
long integration it will take
3.
See how far you are through
the process
4.
Easier to find bugs (depends
on the efficiency of unit tests)
Daily routine:
1.
Everything should be stored
to the Source code management tool (code + properties files+ DB schema + DDLs for
DB configuration + install/build scripts
+ libraries + last stable executable) à
If using a virgin machine, do a checkout, and be able to fully build the system
2.
Take a copy from the source
code management (GIT for ex) mainline (master
in case of GIT) to your machine.
3.
Make your changes + unit
tests (Self-Testing code , TDD preferred)
4.
Build + test
5.
Commit to mainline now (or make a separate
branch till integration tests pass)
6.
Should build (a fast build)
on integration server (Clone of the Production Environment) after each commit (don’t
go home before it succeeds)
7.
Fix Broken Builds Immediately (top priority) : if reason not obvious, rollback then fix, don’t debug.
Rules and Tips:
-
Each build must be accompanied
with running unit tests.
- Should commit to the mainline daily at least.
- Deployment can be automated (preferred) with scripts to deploy /rollback applications into any environment easily, or manual (if automated is slow)
- Should commit to the mainline daily at least.
- Deployment can be automated (preferred) with scripts to deploy /rollback applications into any environment easily, or manual (if automated is slow)
-
If you are not using CI , you
can start first with nightly builds
-
Commit build must be fast (10
minutes ) ,To achieve this, 1) break down the system to smaller parts - 2) the deployment tests (which take most of the
time)can be divided into 2 categories (thus 2 environments) : main short tests(no
DB hits) that is run with the commit build and heavy lengthy tests that can run
afterwards (after I guarantee a correct build) ,
this is called deployment pipeline
-
make sure there's a well-known
place where people can find the latest stable executable.
-
All people should be able
to see build status.
-
Integration environment should
be a Clone of the Production Environment (OS ver, DB ver, IPs, all libs, same
HW) : every
difference results in a risk that what happens under test won't happen in
production.
-
you need multiple
environments, one to run commit tests, one or more to run secondary tests +
prod
-
good ideas for deployment :
1) deploying a trial build to a subset of users – 2) In clustered environments ,deploy
to one node at a time
