About this Article

This white paper aims to help readers understand Continuous Integration and Delivery as a concept and practice in software development projects that follow the Agile methodology.

The content organization is as follows:

The first section explains the benefits of the model.

The next section describes the processes to be established for Continuous Integration and Continuous Delivery.

The conclusion summarizes how Agile methodologies involving Continuous Integration and Continuous Delivery can help improve considerably the customer/market readiness of product releases.

Continuous Integration and Continuous Delivery

Releasing software is a complex and at times arduous process, well known for compelling already overworked professionals to extend their workdays/nights and weekends to ensure that the release is made. It always tends to become a stretched effort despite project scheduling and task estimates.

Over time we realize that the stretch and slippage is because of multiple factors which can be categorized as known knowns and known unknowns that inevitably surface in the course of a release.

Continuous Integration and Continuous Delivery is a practice recommended by the Agile software development methodology which has been able to deal with some of the traditional challenges of development to help product teams optimize and create a streamlined iterative release management process that is predictable to a large extent.

What facilitates the process

Mindset of Minimum Viability: In Continuous Integration and Continuous Delivery we develop a small but fully functional feature-set rather than sweat over an ambitious list of features that inevitably results in partially functional and often a buggy release. The key is to change the mindset of the team. Every team member needs to understand that the customer needs a set of completely working features rather than a big list of partially functioning ones.

Right size Rule: Y.A.G.N.I. or the You ain’t gonna need it principle helps make the change. During product development the team should question and challenge the premise of the release so that we arrive at the “right size” of the release that meets the customer’s expectations of the product.

Benefits

Product watchers have found that typical user communities use only a part of a product’s feature set. For instance, survey statistics indicate that 90% of MS Word’s user community uses just about 10% of its functionality. Hence it is very important to develop the right set of functionality and release to the customer when they need it. The benefits of this approach are multifold.

· Faster go-to-market

Agile teams are better equipped to make interim, small and more impactful releases to meet the needs of customers/market as compared to non-agile teams.

· Smart Product Backlog Management

Features and releases can be made available as per the request and need of customers, and yet at the same time product teams can continue work on their planned monthly or quarterly releases.

· Real time response to Customer issues

Value and viability of a product’s features cannot be realized until the product is delivered to the customers for their use. If delivery and usage is established in cyclic and short time frames the feedback-response cycle can be addressed in almost real time.

The continuous delivery model helps to get iterative and quick feedback from the customers as to what is right, what is wrong and what they really want features to do. By this Agile method, instead of building the whole product we build the smallest possible useful part and give it to users, for validation.

· Customer Delight

In the Agile development model, incremental cycles of two to four weeks of development and delivery enable the development team to release what one can term as the

Minimum Viable Product (MVP) or Minimum Marketable Features (MMF) within projected timeframes. Meeting customer friendly deadlines in this manner indicates that product releases when driven by customer needs leads to a higher level of customer satisfaction.

· Investing in the right areas

One of the real challenges in developing software products is to ensure investments both monetary and effort are channeled in the right direction.

The Continuous Integration and Delivery model helps mitigate the risk that comes with the question “Are we building the right product?” to a large extent. Since this methodology is inherently nimble it enables immediate course correction in terms of ensuring the right features are released to customers. Figure1, gives picture of the itirative processes which form the complete cycle.

Figure 1 (Source: http://www.collab.net/solutions/devops)

· Minimal risk of failure

It is important to have the features ‘Production ready’ always, even after changes are made to the code, database or configuration. Incremental development, testing and release

reduces the quantum of ‘untested’ or ‘unreleased’ features as illustrated in Figure 2. This not only makes it easier to control the quality of the deliverable but also enables easier roll back to the pre-change state, in case of failures.

Figure 2 (Source: http://www.collab.net/solutions/devops)

Core principles of the Practice

1. Continuous Integration – across sites and timezones

The essential requirement here, for the multi-function teams – development, testing and documentation, is that the features are continuously built, tested and integrated. This process also supports teams working in multiple geographical locations and across time zones to effectively collaborate and deliver fully functional releases.

· Test as you develop the product

The cost of quality of any software product is closely tied to the time of finding errors in its functioning. In other words, for every bug detected early in the development process, the cost of quality reduces dramatically.

In a typical waterfall project we get to the testing phase in a sequential manner after the development phase is completed. This not only delays the point of catching defects but also increases the impact of the bugs in the form of re-work which in turn impacts delivery schedules. One way to mitigate the risks of increase in cost of quality and impact due to missed deadlines, is that testing should go hand-in-hand with development.

The question is can this be done? Figure 3 explains the process flow which can help to resolve this issue.

Figure 3 (Source: http://www.dynacrongroup.com/about/continuous-delivery/)

The key is to continuously integrate development and testing activities in a manner that enables software to get tested incrementally along with development so that the issues get detected and fixed at the earliest.

· Automate the Build process

For product testing to be in synch with development so that it is effective, the QA team has to have their test environments (also known as the QA Build) ready at any point in time to be able execute their test cases. The key requirement here is to have a process that “builds and delivers” the QA Build on a regular basis. Automating the build creation process becomes key in order to ensure that the QA Build is ready for deployment well before the QA team is ready to start testing. Further, this automation also releases considerable amount of time for developers to focus on core development activities as opposed to tasks associated with the process of packaging and building the release for testing.

Ready to use build-automation applications can be used to establish such an automated build mechanism.

For the purpose of this paper, we refer to the following tools:

· Microsoft Unit Testing framework – used to execute automated service testing for every

check-in

· FinalBuilder – used to automate the generation of a daily build. Figure 4 shows a snapshot of FinalBuilder setup.

Figure 4

· Build the product on every code commit

For build-automation to be successful, integrity of the code-base has to be such that the software product can easily be compiled without any error. The bigger the code base the higher the risk of integrity-loss and error free build.

For example, in a team of 40+ developers if every developer encounters even an hour of code-integrity related issue it leads to a 40 hour loss in productivity. It is therefore very important that every piece of code written, is checked-in or committed to the main baseline at least once in a day so that the next build can reflect the updates.

Use of the testing frameworks such as Microsoft Unit Testing framework to execute automated service testing, helps ensure that the impacted services work as expected with every check-in. A snapshot of such unit test configuration is given in Figure 5.

Figure 5

The build-automation process must trigger a build after every commit to the main baseline code base and it must also ensure that there are no build related issues after every

check-in/commit.

Tools such as FinalBuilder reports check-in issues to the concerned developer. An integrated messaging and reporting system built into it reports build-failures to a team of build owner(s). As a result the build owner(s) can immediately log in (even from home) to resolve the reported issue, thereby minimizing the risk of non-availability of the QA Build for the testers on any given day. This particular ability allows distributed agile teams to work effectively withou any loss of time due to possible time zone issues. The QA team starts every day by installing a fresh build to carry forward product testing. Automating a timed-install of the QA Build can make it even better by freeing the time spent in manual installation for testing.

· Automating regression testing

The Scrum model usually discourages manual regression testing. This is because in a development cycle defects are expected to be fixed and closed during the scrum cycles – known as sprints. There is no room for defects to creep to a ‘regression test cycle’ in this methodology. In real practice however, despite incremental development and testing there can be integration or system level issues that necessitate additional testing. Assigning resources to such testing can lead to unavailability of testing bandwidth for the planned sprints. The recommended practice to minimise time and resource investment for regression testing will involve the following steps

o learning from the previous regression cycles

o identify such defects or patterns of defects

o set up automated procedures for testing them

o run the automated procedures regularly to test the stability of critical functionality

· Simulate a production-like environment for daily testing

Considerable time and effort is spent by developers and testers trying to replicate reported defects It is therefore very important to simulate the real-time environment to enable effective testing of software. For all practical purposes, there should be a production like environment that mimics the actual set up at the customer site. This allows the QA team members to not just catch the functional issues but also test the environment or installation related parameters as well.

2. Continuous Delivery – to the “remote” customer

The essential requirement here is to deliver to the customer who is “remote” in relation to the development teams.

· Delivery Pipeline

The Continuous Integration processes both manual and automated, create a pipeline of steps where one process or step waits for the previous one to be complete.

If not well planned, this approach poses the risk that it will not be possible for the product team to optimize the time for complete deployment. This situation as illustrated in Figure 6, is termed as ’Insufficient Parallelization’.

Figure 6 (Source: Continuous Integration, Martin Fowler & Jez Humble)

The most preferred way to overcome this is to make the pipeline as wide and short as possible. Conscious effort has to be made to eliminate the risk of queuing up the processes. Figure 7 illustrates how to bring in parallel processes to decrease the waiting time for deployment.

Figure 7 (Source: Continuous Integration, Martin Fowler & Jez Humble)

· Automated Continuous Deployment

Continuous Deployment is a part of the Continuous Integration and Continuous Delivery process where every build gets deployed into a production like environment. This environment can be used by the QA team or even the customers. Any such deployment can happen easily with an automated process in considerably less time as compared to manually deploying the application components.

With the latest software always made available to customers for exploration and use at their own time it has given them great flexibility to use and validate regular releases.

· Automated Acceptance Test

Acceptance Testing (AT) is very much a relevant process that contributes tremendous value in the development and release phases. It is the most effective way to know if the software is meeting the objectives of the customer . It answers the question- are we building the right product?

Teams create one or more AT for each user story to ensure that the feature works per expectations. The acceptance test process is automated with the test results made visible to the stakeholders. As active stakeholders, customers are responsible to check the results and set the priority for resolution of the reported cases. Ultimately it is the responsibility of the development team to allocate time to correct the features that have failed the acceptance tests.

Conclusion

In today’s world customers are not prepared to wait for long time-frames to receive features and then find out that the product is only partially meeting their needs. This has intensified the challenge for software development organizations to find ways to deliver periodic releases as and when the customers want.

We believe Continuous Integration and Continuous Delivery is gaining more acceptance in the industry because of its capacity to enable teams to deliver solutions of value, in considerably shorter timeframes.

Industry studies report that most organizations take to Agile methodologies very well in the engineering phase but almost always follow a more tradtional release plan of doing a few fixed releases a year. Here again, Continuous Integration and Delivery can help release well tested list of features in small bit sized chunks that lead to greater adoption by customers . There are industry figures that indicate upward of 80% improvement in testing and release effectiveness, when this methodology was deployed.

The approach being very much customer centric ensures that the customer is co-opted into the development process, and results in an inherent commitment on the part of the customer to adopt the product and use it. This leads to a win-win relationship both for the customer as well as the vendor developing the software.

References:

1. Rapid Development: Taming Wild Software Schedules, Steve McConnell, Microsoft Press, 1996.

2. Continuous Integration, Martin Fowler & Jez Humble

3. Wikipedia : http://en.wikipedia.org/wiki/Continuous_integration

4. http://www.extremeprogramming.org/rules/functionaltests.html

5. http://continuousdelivery.com

6. http://www.dynacrongroup.com/about/continuous-delivery/)

7. http://www.collab.net/solutions/devops

Here is what I think

Thursday, 16 May 2013

Social Gaming : Changing face of Computer Games

Friday, 28 December 2012

Smarter Release Management with Continuous Integration & Continuous Delivery