An Agile Approach for Achieving Continuous Integration and Continuous Delivery
Introduction and Scope:
Despite a team’s best intentions and efforts, many struggles with software that arrives late, is of poor quality or simply fails to meet the needs of its users. Recently some organizations have adopted a fundamentally different approach called Continuous Integration and Continuous Delivery (CICD).Continuous Delivery (CD) is the application development discipline that takes Agile to its logical conclusion, creating software that is always ready to release. It does this by building upon and extending Agile, CI and DevOps practices and tools to transform the way software is delivered. This iterative and incremental development practice gave rise to Continuous Integration (CI) is a practice of checking-in code often, with each “chunk” tested and integrated into a shared “trunk” several times a day.
Business benefits:
- Increase your code coverage
- Deploy your code to production
- Never ship broken code
- Decrease code review time
- Build repeatable processes
- Run tests continuously for every change
- Any failures can be fixed right away
Research/ Study content:
- Research was carried out to find various business importance and need for going CICD in Agile approach to optimize entire software development process
- Through out of 8 years of my professional career, I closely observed both agile and non-agile projects and got feedback from various teams
- Focused on test automation and presented best practices and challenges to overcome to achieve CICD in Agile environment
Abstract
Continuous integration in agile development
Since a decade or more, software teams have been benefited from the agile development methods. They adopted these iterative and incremental development practices, where solutions evolve through collaborative development. Traditional, non-agile approaches to creating software typically rely on a more regimented flow of development. An example of this is the waterfall process, where each activity of requirements, design, development, and testing is done serially.
Although waterfall development was the standard for large, complex system development for many years, it has several notable flaws. The first is that a lot of work is wasted trying to complete documents before designs and designs before code, even though it is well known that the requirements will change over time. Another is that, in holding off on testing and integration until the end of a project, issues are frequently discovered too late to be resolved without causing missed deadlines. These two factors, combined, might have been tolerable in a world that moved at a slower pace. But as the pressure to create innovative systems has increased, the ability of that approach to meet the needs of organizations has decreased.
When applied as part of an architecture-based approach, continuous integration (CI) and test-driven development (TDD) extend basic agile practices enough to provide both high quality and project flexibility. This paper explores how agile methods, CICD ( Continuous Integration and Continuous Delivery) , various Testing Techniques and various best practices can be employed make CICD reach its goal.
CI and TDD in Agile
We knew agile methods by now. The concepts that they brought to software development changed the way teams organize their work, adapt to changing requirements, and release software. Continuous integration (CI) was created for agile development, so the agile approach is the context for any CI discussion. It organizes development into functional user stories. These stories are prioritized into smaller groups of work, or sprints.
The idea is not to try to solve every issue up front but, instead, to focus on what you already know. So the team designs, builds, and tests what they know about the desired functionality. This creates a working product based on a subset of the complete product's requirements. Then the team moves on to the next-highest priority set of requirements and repeats the process. Of course, this is a very simplified view, and there are many variants of this process, but that's the core: Build your product incrementally, and try to improve things as you go.
According to Martin Fowler of ThoughtWorks, continuous integration is a software development practice that requires team members to integrate their work frequently. Every person integrates at least daily, which leads to multiple integrations each day. Integrations are verified by an automated build that runs regression tests to detect integration errors as quickly as possible. Teams find that this approach leads to significantly fewer integration problems and enables development of cohesive software more rapidly.
This leads to the final detail that makes for successful execution of a CI process. If the idea of continuously integrating is to find issues quickly, thus giving each developer feedback on their work, then there must be some way to evaluate that work quickly. Test-driven development fills that gap. With TDD, you build the test and then develop functionality until the code passes the test. As each new addition to the code is made, its test can be added to the suite of tests that are run when you build the integrated work. This ensures that new additions don't break the functioning work that came before them, and developers whose code does in fact "break the build" can be notified quickly. A typical combination of continuous integration and test-driven development is illustrated below.
An agile practice using continuous integration and test-driven development
CI and BDD in Agile
Behavior-driven development (BDD) is an extension of test-driven development that encourages collaboration between developers, QA, and non-technical or business participants on a software project. It extends TDD by writing test cases in a natural language that non-programmers and domain experts can read. BDD features are usually defined in a "given when" and "then" (GWT) format, which is a semi-structured way of writing down test cases. A BDD feature or user story needs to follow the following structure:
- Describe who is the primary stakeholder of the feature
- What effect the stakeholder wants the feature to have
- What business value the stakeholder will derive from this effect
- Acceptance criteria or scenarios
Best Practices in Continuous Integration
We have to follow few best practices and key principles to make Continuous Integration achieve its primary goal. The most important practice is, establishing the ritual of Continuous Integration and Continuous Deployment. This eliminates the need to authorize and delegate from the top. It is automated and self-triggered. Few are listed down here.
Continuous Integration enables Continuous Deployment
Continuous Integration and Continuous Deployment are connected concepts and are fundamentally refer to the software release in the live environment with automated tests. With Continuous Integration and Continuous Deployment you are not just reducing risks, but catching bugs in time and getting your software/application ready for the market.
Ultimately, when the risks get lowered, it helps prompt adaption to business requirements and the consumer demands. It further enables greater collaboration between Operations and delivery, maturing the release process for competitive advantage.
Continuous Integration with the right approach
Continuous Integration is usually implemented with Agile, Test-Driven-Development (TDD) or Behavioral Development (BDD) and Test Automation. If implement in this flow, Continuous Integration can prove to be an obvious fit for your development process and can help reduce the challenges for better results.
The idea is to adopt select an appropriate tool that fits the existing technology ecosystem that fits in effectively within your existing development environment. Continuous Integration helps build and integrate the software frequently. Moreover, it is recommended to execute unit tests as part of the overall integration process.
Detect early, Resolve faster
Faster detection of issues/defects helps resolve the problems faster. If the integration and software development process does not incorporate testing, the overall cycle can go reverse that will further incur risks. When the development team strives to add new features to the code and detect bugs, the code’s health can go for a toss. At the same time if you have Continuous Integration server in the process, it helps you keep your software in a better shape.
Segregate software builds from deployment
Continuous Integration helps you to completely separate the build and deployment process, where both are treated as independent activities with no specific dependencies. While the developer may focus on the build process, integration could be taken up a sole activity by the testing team. The Continuous Integration server can trigger a developer’s check in for integration and a tester’s check-in for deployment.
This helps kill the dependencies and enables dedicated attention. It helps to identify problems with the build at an early stage and move progressively towards getting the software in the production environment.
Continuous Integration with Test Automation
Whether you adopted Test Automation or are considering it for faster test cycles, Continuous Integration is here to enable you. When the recurring and repeatable tests are automated, it helps teams to deliver better and faster. Continuous Integration powered with Test Automation helps cut manual efforts and helps testing and development teams to look at the SDLC process more creatively.
When it comes to testing, identifying the failed codes is more important than bragging about the successful ones. It is bound to make your software/application stronger.
Continuous Testing with Agile
Continuous Integration with Agile methodology helps gain speedy delivery by ensuring quality. Project Managers and development teams are advised to implement continuous integration in the overall release management strategy. The overall SDLC process – write, build, integrate, test, debug and deploy can be complex.
The Agile process enables flexibility and helps teams go back and review the build for accuracy. This further helps improve delivery time and releases testers to look beyond the obvious in the process.
Continuous Integration for transparency
At a broader level, Continuous Integration helps provide transparency to the overall Development and Quality Assurance (QA) process. It helps indicate failed tests and the reasons for that failure, which further helps in leading to some logical reasoning and required action for improvements.
Continuous Testing for reduced bugs
Bugs and defects are an inevitable component of the SDLC process. With Continuous Integration the instances of bug accumulation gets reduced substantially. Thanks to the overall automation it provides, bugs are identified early and risks are reduced.
Continuous Integration for Automated Regression Tests
Continuous Testing facilitates automated regression tests, where Test packages hosted in the QA repository can be maintained and implemented by multiple QA team members and executed whenever a new code is deployed to the environment.
When every new defect gets added to the automated test case, it becomes easy to effectively build a substantial regression testing suite. This enables automation of the regression tests and reduces the efforts of the testing teams.
Smoke Tests with Continuous Integration
As mentioned earlier, Test packages written by QA and maintained with the Continuous Integration systems can help automate the build and test process. Further Smoke Tests can be written to monitor the production system and deliverables can be made available for a wider group by testing the software at various stages.
Continuous Integration comprises automated deployment, deployment scripts for testing every build to ensure that no code related issues arise in the production.
Importance of Continuous Integration in Continuous Delivery
With current business demands to accelerate time to market, we see more teams migrating from traditional development models to continuous delivery based on Agile development methods. CD is driven by CI. In CI, the code is logged-in several times a day and then re-compiled, generating multiple QA feedback loops. Thus, it is necessary for development teams to collaborate and make frequent deployments, which mandates greater levels of process automation. Also, to successfully apply CI, automation of the build and deployment process is critical; this ensures a self-testing build and makes the entire process transparent and agile.
Challenges in Automating QA in Continuous Delivery
As specifications evolve and must be continuously integrated into a product’s final code, the time and scope for a release in the development cycle are limited. Moreover, frequent builds may also decrease the stability of the code. Hence, it is crucial to address QA in a more robust manner. Often, during Agile development projects, the functionalities and UI change across multiple Sprints; hence, automating QA is far from an easy task. In our engagements, we have experienced the following test automation challenges in Agile delivery projects:
Ensuring test coverage: As code is integrated continuously, chances are that critical tests for a particular requirement could be missed. Also, unanticipated code changes could lead to limited test coverage during automation.
Costlier defect fixes: Where test coverage is not complete, defects that belong to an earlier Sprint are detected much later in the development cycle. Once the application is in production, these defects prove to be significantly costly to fix.
Compromise of user performance: As software features are added incrementally, more lines of code are generated, leading to performance issues, especially if development teams are not aware of the impact that code changes could have on end-user performance. As developers work in collaboration with testers, it is important to ensure that persistent, rapid testing and fixes are performed continuously.
Thus, despite the above challenges, CI automation will play a critical role in expediting the delivery pipeline by completely eliminating wait time, and it sets the foundation for CD. These challenges all need to be duly addressed to ensure seamless CD. We can follow few automation techniques to achieve this.
Automation Technique #1: Achieve Continuous Regression
QA organizations must keep pace with evolving development methodologies. As automation becomes inevitable in Agile development world, it is important to automate early for CI and CD. Through early automation, the building blocks of automation are applied much earlier in the Agile development cycle. Early automation enables efficient and automation-friendly test designs, feeding in to an efficient functional cycle. As a result, continuous regression that exercises iteratively-built code results in a stronger automation foundation. Below figure depicts our approach to early automation.
Through early automation, functional testing is fast-tracked. This approach not only reduces the efforts of repetitive functional tests prerequisites, but expedites overall functional test execution. Early automation helps teams to move data-driven functional tests directly to automation.
Automation Technique #2: Think Before UI
In CI, the UI layer is built over successive iterations. However, a complete user interface is not available for UI-based automation. Therefore, QA organizations must consider unconventional automation models to automate early. Applications with multitier architectures built on Web services/APIs, messaging middleware and databases pose an opportunity to validate business rules, logic and functionality at intermediate layers as well as on back-end systems. They communicate with each other through messaging protocols, but most of the critical business logic resides in the database in the form of various database objects.
Looking beyond UI creates opportunities to utilize the communication layer to simulate any upstream application behavior, thus reducing the dependency on upstream applications. Similarly, any downstream check on the data flow can be performed by verifying the status in downstream databases or validating the returning messages. We have built a few utilities around message-based validation and database object validation which can be used to enable component automation.
Automation Technique #3: Optimize Testing at Code Level
Conventional requirements-based testing of code changes tends to result in considerable over-testing without the guarantee of complete coverage. The impact of missed tests on coverage and quality is significant in CI. This typically results in additional QA cost and extended testing timelines, that in turn impact project success. We developed a solution that automates the impact analysis of code changes to affected test cases by scanning the application build and by automatically mapping code components from the build to test cases. This ensures optimized testing while maximizing test coverage.
Automation Technique #4: Minimize Manual Intervention
As development and testing increasingly run in parallel, stakeholders need better collaboration. Development teams achieve greater collaboration if they are able to select the right tools, frameworks and methods to automate CI. The selection of the right tool could help in improved deployment success and minimize the broken builds.
Development teams achieve greater collaboration if they are able to select the right tools, frameworks and methods to automate CI.
References & Appendix
Author Biography
Balaraju Chinthakindi is an automation senior consultant in AIG, taking care of all Selenium automation related projects. With above 8 years of professional experience having sound knowledge on Test Automation and Automation Frameworks and successfully delivered complex projects.