Continuous Delivery – Continuous Integration
Part of the reason why the traditional ways of developing software for customers has failed is because of they weren’t getting what they wanted or needed in time. Customers realized that the deliverable isn’t exactly what they needed or wanted and that too after spending significant amount of money.
What am trying to explain thru this blog is by decoupling various jargon used in Agile conversations.
Continuous Delivery is what the customers or stakeholders expect. For this to happen we need to develop software in small chunks. [why – because large chunks take time and that is not what we are talking about] Next – when you develop software in smaller chunks in short windows of opportunity (sprints – scrum/ iteration – XP) we need to have a Continuous Integration. What happens here is we test [Unit and Regression] smaller chunks by integration to the master code base and keep the software ready for release. The defects of course have to be fixed before we release the software to production for customer usage.
For the above to happen regularly and seamlessly – the following are extremely (cannot emphasize more…) important to have in place.
- Simple architecture, design, coding principles – to make changes easily
- Automated Test Scripts ready to test the code continuously – no scope of escaped defects
- Customer Collaboration – Stand-ups to Demos to Review to Backlog prioritization
- Transparency – If there is risk of any sort, should be brought to attention of pretty much everyone [customer, development team, stakeholders, entire project group]
- Knowledge Sharing – very essential for the team to keep sharing knowledge – technical, functional. Again documentation is required for quick references but barely sufficient.
To conclude – nothing in agile is long term. We keep experimenting new ideas, stuff, reflect and adapt to new trends in “how we do things”.