Greetings,
Think about the projects that just go through the building phase for years and when the building phase finishes; nobody has clue how much time more to integrate or even where to start for the integration? People who have spent great deal of time coping with these problems have thought of a noble concept called Continuous Integration.
It is development practice where team would integrate their work frequently; usually multiple times a day leading to many integrations in a day.
If you have not worked in such an environment, you will simply frown upon the idea. The best way to move forward is to adopt Continuous Integration approach; which makes the Integration a non-event or a integral part of coding. It is a concept which involves many other small practice adoptions. Let's discuss them in brief..
+ Single Source Repository - It is all about maintaining your code in a good-quality source code management system like Perforce, SVN. Even CVS will do but not as good. You will use it anyway as multiple people work on the multiple files of the same project.
+ Automate the Build - Build is the key here. When you are required to run multiple builds in a days; you can't afford to have manual and slow build. Build must be automated with tools like Cruise, ANT, Maven etc. Try every possible way to make the build as fast as possible. Typical build should not take more than 15 mins otherwise people loose charm of the practice and loose more than you aspired to gain out of multiple build practice.
+ Automate Tests - Build doesn't mean compiling, linking the code with some libraries to create a codebase that runs. We also need to ensure that the final codebase does the right thing. To achieve that, just write tests using any of the Testing frameworks like jUnit. Create a test suite; make it an integral part of the Build. Now, whenever build runs, it also runs the entire suite of tests on the codebase. This approach is also better known as Test Driven Development or simply TDD. Well, one can argue that tests can't prove the absence of bugs but if we can cover even 80% of functionality with automated tests; it will be huge time saver.
+ Commit Daily - Frequent Integration is basically meant for a developer to inform the changes to other developers in the project. More and frequently developers know the changes made to project; lesser are the chances for code to fail.
+ Commit-Build Integration - It may look confusion to start with. But there are 2 parts. First part is to build on developer's machine and commit ONLY if build is successful. Second part is to build on *integration machine* as soon as you commit. You can run manual build on integration machine or automate this step using tools like CruiseControl. This step ensures that whatever you have committed just now holds good for Integration machine as well; implies that your code has successfully integrated with other developer's code.
+ Transparency - As you might have understood by now that it is more about communication.. with accountability. Not necessarily required but if you can use a tool that can provide you a dashboard that gives you the recent snapshot of what's going on in the project's codebase. Example - who is building? Build by X failed? Reasons why X's build failed? How many developer builds failed per day/week? how many integration builds failed? and more importantly..who is making what changes?
+ Automate Deployment - Typically, you have multiple environments. Local developer environment, QA environment, Staging Environment and Production environment to think of few. You must have the scripts that can build, test and deploy to any environment of your project. The process becomes speedy and less erroneous. Another important thing to look for is the Deployment Rollback and restoration to previous state...anything can go wrong anytime and you would like to go back to last good state ASAP; at least in production.
Following these simple BUT effective practices; you can save a lot of surprises that emerge with an event called Integration Phase.
~ Happy Integration...continuously.
Navjot Singh Sohanpal
Think about the projects that just go through the building phase for years and when the building phase finishes; nobody has clue how much time more to integrate or even where to start for the integration? People who have spent great deal of time coping with these problems have thought of a noble concept called Continuous Integration.
It is development practice where team would integrate their work frequently; usually multiple times a day leading to many integrations in a day.
If you have not worked in such an environment, you will simply frown upon the idea. The best way to move forward is to adopt Continuous Integration approach; which makes the Integration a non-event or a integral part of coding. It is a concept which involves many other small practice adoptions. Let's discuss them in brief..
+ Single Source Repository - It is all about maintaining your code in a good-quality source code management system like Perforce, SVN. Even CVS will do but not as good. You will use it anyway as multiple people work on the multiple files of the same project.
+ Automate the Build - Build is the key here. When you are required to run multiple builds in a days; you can't afford to have manual and slow build. Build must be automated with tools like Cruise, ANT, Maven etc. Try every possible way to make the build as fast as possible. Typical build should not take more than 15 mins otherwise people loose charm of the practice and loose more than you aspired to gain out of multiple build practice.
+ Automate Tests - Build doesn't mean compiling, linking the code with some libraries to create a codebase that runs. We also need to ensure that the final codebase does the right thing. To achieve that, just write tests using any of the Testing frameworks like jUnit. Create a test suite; make it an integral part of the Build. Now, whenever build runs, it also runs the entire suite of tests on the codebase. This approach is also better known as Test Driven Development or simply TDD. Well, one can argue that tests can't prove the absence of bugs but if we can cover even 80% of functionality with automated tests; it will be huge time saver.
+ Commit Daily - Frequent Integration is basically meant for a developer to inform the changes to other developers in the project. More and frequently developers know the changes made to project; lesser are the chances for code to fail.
+ Commit-Build Integration - It may look confusion to start with. But there are 2 parts. First part is to build on developer's machine and commit ONLY if build is successful. Second part is to build on *integration machine* as soon as you commit. You can run manual build on integration machine or automate this step using tools like CruiseControl. This step ensures that whatever you have committed just now holds good for Integration machine as well; implies that your code has successfully integrated with other developer's code.
+ Transparency - As you might have understood by now that it is more about communication.. with accountability. Not necessarily required but if you can use a tool that can provide you a dashboard that gives you the recent snapshot of what's going on in the project's codebase. Example - who is building? Build by X failed? Reasons why X's build failed? How many developer builds failed per day/week? how many integration builds failed? and more importantly..who is making what changes?
+ Automate Deployment - Typically, you have multiple environments. Local developer environment, QA environment, Staging Environment and Production environment to think of few. You must have the scripts that can build, test and deploy to any environment of your project. The process becomes speedy and less erroneous. Another important thing to look for is the Deployment Rollback and restoration to previous state...anything can go wrong anytime and you would like to go back to last good state ASAP; at least in production.
Following these simple BUT effective practices; you can save a lot of surprises that emerge with an event called Integration Phase.
~ Happy Integration...continuously.
Navjot Singh Sohanpal
No comments:
Post a Comment