By now you must be thinking what is this guy up to ?? when agile manifesto says "Individuals and interactions over processes and tools" which to me or may be to the manifesto in itself would relate the tools for tracking and logging and not the DBT environments, hence every developers / testers prefers having a definitive process for the story transition from one state to another state remembering not going away from the manifesto.
Now whats a smooth transition of a story ? lets assume we have picked 5 functionality which sums up to 50 stories in our current sprint , i should be able to achieve this in 5 days , considering my working hours is 5 and my capacity is 2 developers/testers. an ideal state assuming so !! now lets get to the transitions.
Environments plays a vital role on every state , how do we make sure that at every state we keep doing the right thing and make sure we "release early and release often" to the test , to get continual feedback and make sure at the end of sprint we have a tested working piece.
Continuous Integration (CI) - Continuous integration involves integrating your code early and often (ideally after completion of a story , may be a defect fix or a code refactoring and not otherwise), so as to avoid the pitfalls of "integration hell". This practice aims to reduce rework and thus reduce cost and time, most importantly immediate feedback on your check-in.to achieve the best of CI , one has to follow the best practices of CI the first and most important being "Before any code commit , make sure you get the latest code from the source control , build the solution on local and make sure there aren't any build errors." as the source control could have been updated by any others code commit.
setting up the CI and auto deploy could be another topic worth covering , may be in the future posts.
now getting deep in to asking ourselves more questions on why should my CI be in place for a typical agile environment .firstly it helps developers detect and fix integration problems continuously - avoiding last-minute chaos at release dates.more advantages like
- early warning of broken/incompatible code
- early warning of conflicting changes
- immediate unit testing of all changes
- constant availability of a "current" build for testing, demo, or release purposes
- immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing
- frequent code check-in pushes developers to create modular, less complex code
- metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, also we have a host of plugins available for CI.
when there's so many advantages there should be some disadvantage as well as consolation for those who doesn't want to use CI , but in my view we should call them as investment than a disadvantage, the investments would be like
- initial build box setup time required and getting developers up to speed with training on CI tools.
- well-developed test-suite required to achieve automated testing advantages
- Dedicated build machines.
Tools Available
Most widely used would be Hudson and Cruise Control .net, teams using TFS2010 are getting used to the build in CI tool you can find the comparison chart of different tools here , my personal pick is CC.Net probably because we have been using it longer than any other.
well to sum it up , the right kind of CI would certainly reduce deployment and release overhead on the dev and test teams , also an easy way to maintain clean code and running solution any time !!!
Release early release often !! go CI way..
No comments:
Post a Comment