Implementing Continuous Delivery

This is continuous of previous  post "Continuous deliver - Introduction"
When we think of Continuous Delivery, mostly we think a lot about the tools which is important  however, the real challenge come because of existing design of your system specially when it is monolithic architecture, which slow down the developer and de-motivate them to do re-factoring for project betterment.
Here are few of many challenge with monolithic architecture
1. Build: Everything is configure to run under one build task which slow down the build and application start-up time.
2. Test Case: Test suites tend to grow too large, making the feedback loop slow which is a kind of an enemy instead of a companion.
3. Single Project for all code: This compound above two problem, also  result into less ownership when multi-functional team work on such project.
4. Management: Hard to manage technical debt.
Here are some step toward resolving those challenges.

Convert the project into multi-module project

Split the monolithic application into multi-module, you may not be able to move the source code quickly , however create the module and move the test cases into respective module should be easier and less risky, then create the separate jenkins pipeline for each module.
Advantage
1. Each module has its of development pipeline
2. Focused Ownership as each functional team will be responsible for its own module
3. Quick feedback as module specific test cases are executing instead of large test suite
Tools
Gradle: Customize the build script to create the multiple module project, gradle also has a capability to allow the parallel task execution
Project Structure

 (root)Project\build.gradle
 (Module1)Project\Module\Module1\build.gradle
 (module2)Project\Module\Module2\build.gradle

Categorize the test cases

Small/Unit test: 
These are method level unit test case  which runs in memory and in isolation without any dependency, below are advantage of these test cases
1. They runs real fast, so should be triggered for each commit
2. They are primarily useful for developer to understand the code and design , it motivate the developer to refector the code  as there is test case to validate it.
3. Helps to collaborate well among the developer
Medium/Component test/
Module level test case, test each component in flow
1. This should also run quickly, important test case should run as a part of development pipeline, all test case should run as a part of master pileline (before reaching to QA)
2. No mock for component in flow
3. Mock other modules/external dependency
4. They are primarily useful for business to ensure business test case are green and covered
Large test/Integration test/
Application level test case which test entire flow(excluding external dependency).
1. They are slow in nature, they should run as a part of qa pipeline.
2. No mock for any component in flow
3. Mock or test account for external dependency
4. Primary useful to test the integrity of the system
Source folders

src/test – unit tests
 src/test-component –  Component tests
 src/test-integration – integration tests

practical challenge: If the existing project does not have enough unit test case and organization may not invest on unit test case as it does not add any business value, possible solution could be to convince the management to invest on component/medium test as it validate the business and reduce the regression testing effort
Tool
Gradle: Use to categorize the test case, configure each catagory as source folder and run each test category as separate build step
TestNG: Use testNG to execute the test case in parallel.
Selenium: To run UI/component  test

Code coverage

Code coverage is a way of ensuring that tests are actually testing the code. It helps ensuring the quality of tests, not the quality of the product under test.
Why code coverage
Testing by themselves do not provide enough confidence unless we know that they cover significant code coverage. Having all tests successful while, for example, covering only 15% of the code cannot provide enough trust.
In general code coverage is tie to unit tests but it should be used with any type of testing including integration/functional/manual testing
Tool
Jacoco: can be used to capture the back-end code coverage, it has two step first- capture the coverage, second:- decompile the coverage data and generate the html
Istanbul: can be used to capture the javascript code coverage.
Gradle: gradle has inbuild plug-in support for jacoco
Jacoco can be configured as agent jar to server so that it can capture the data for manual testing as well.

Provision Deployment environment

Use Docker to provisioning environment which is recreational  with every build, web server (tomcat ect) /db/ selenium hub-node everything should run inside its own container with linked each other
Advantage
1.Tear down and create the environment with every build, Infrastructure as code.
2.Application is deployed and bootstrap in isolation and in reproducible environment
3.Docker container are version controlled
4.Developer push the image and Jenkins pulls the container in different environment

Pipeline as Code

1.Jenkins is used as CI tool
2.Jobs maintenance is pain
3.programmatic creation of jobs (job ds and, Pipeline plugin)
Tool : Jenkin DSL is groovy based scripting language which support to generate the jenkins job.