Continuously integrate software and everything around it

Continually integrating code increases velocity and quality

While you are working away on a project or a paper, its easy to handle all the modifications on your own, since you are the only author. Things get interesting when many authors need to use the same source.

Integrate early and often.

Especially when you have the very first thing working, and you have a unit test and functional test doing the bare minimum; take a moment to integrate with the larger project, commit changes to the branch and generally harden the edges around what is newly build. 

Once the resulting leaner version of feature is in the build, expanding on that feature is done more effectively as you have the build cycle moving with everything intact.

Automate the building of the software. Once the scripts are done (and they are way easier than everyone seems to think they are) the project builds itself every night. Why not do this? Everyone is home sleeping, and the computer at the office are just running idle all night. Use that time.

 
The build script, like all scripts, start small and go from there. The build script should do the basics:

• Clean the source directory.
• Sync code into staging area for building
• Build all source in staging area. Full build too; no incremental, or half build shortcuts. Build dependencies, and any inclusions.
  Build target libs and place into target directories.
  Build binaries and link all necessary libraries.
• Clean all intermediary files
• Package binaries and libs for distribution
• Configure target machine for deployment
• Check network configuration
• Deploy binaries and libs

Each step some reporting can be done and the results archived. The script runs at night when everyone is asleep. The results are ready the next day, and everyday.
Polish your build!

 
CONTINUOUS INTEGRATION

• Integration is the assembly of all the parts to end up with a deliverable 
• building, testing, packaging, deploying.. 
• One person doesn’t need an integration effort, but more than one person does 

INTEGRATION

• Artifacts are created: source code, and other dependencies 
• Source from different places has to end up in one place 
• There are many options, but using a source control tool is the best practice. 

SOURCE

• A common, neutral build is necessary. 
• ‘Works on my machine’ works if you are distributing your machine 
• A common build machine/environment eliminates local dependencies and gives confidence it can work elsewhere 
• When to build all this? Weekly? Daily? 

BUILDING FROM SOURCE

• Once the source compiles, how do you know it works at all? 
• Manually running the build and exploratory testing can take you so far 
• Having unit tests can give more confidence that the code that is tested will work 

TESTING THE BUILD

• You can just zip up the compiled source, email it somewhere and run it… 
• Error prone, it’s easy to forget menial steps 
• Time consuming as new dependencies are usually found as a result of things ‘not working’ 
• Run those tests to give confidence that all tests will pass. Tests that aren't in the dependency tree shouldn't be affected. Make unit, integration and functional tests run separately or all at once

PACKAGING FOR DEPLOYMENT

• Building, testing, packaging, versioning and deploying define a process 
• If it is a defined process, it can be repeated. 
• It’s ‘defined’ if you did it once. Never wait for a master plan to start, just evolve the plan as you go. 
• The build is ‘broken’ if the entire process doesn’t complete. 

IT’S A PROCESS

• Once the process is automated, run the process as much as you can, not ‘when you need to’.
• Always look to automate any repeatable process. 
• Run the process continuously and be aggressive about finding more tasks to automate 
• Why do all that work when a computer can do it for you? Computers just sit around all night and they don’t get tired. 

AUTOMATE EARLY AND OFTEN

• Spend your time actually building the technology, not doing the housekeeping around it.
• Automate the source and change control, the build and packaging, the testing and verification, and the deployment 
• Only one trigger is needed: when the source changes. 
• Run on every change, every hour, all night… all the time. Who cares? It’s automated. 

CONTINUOUSLY INTEGRATE EVERYTHING

• Continuous integration tool: ’Hudson’ 
• Source Control: git 
• Building: using compilers specific to the code base 
• Metrics: running analysis tools on codebase 
• Testing: running unit tests on every build 
• Metrics: running more analysis tools on built codebase 
• •Packaging: auto deploying to development environment 

PRODUCT

• Allows builds anytime that have aligned versions

Wrap it up

Continuous integration is a great strategy to automate a lot of quality into your application, and over time you will end up saving a lot of time and increasing the general quality of the technology that you are making.

Its a process; do a little each week and the results will quickly build up over time.