Page 35 - GCN, May 2016

CHECK THE BUILD
Unlike the waterfall method, agile development involves continuous integration and testing throughout the process on the application build itself, instead of individual components.
Unit tests check the internal application logic. This is the first line of testing that ensures the application is behaving as expected.
If the test indicates failure, the continuous integration/ continuous delivery (CI/CD) server stops the pipeline and notifies the team of the failure and the cause.
Once the error is fixed and a code or configuration correction is pushed to the SCM, the SCM detects the change, and initiates the build pipeline again along with all necessary testing.
THE HUMAN TOUCH
Once the integration tests succeed, the
build is passed on to the next quality assurance stage which could contain not
only functional testing but also performance and load testing environments. That’s often done automatically and can even happen in parallel to other
stages, expediting the process.
There’s one exception: If any user interface (Web
pages, mobile pages, and so on) is involved, your agency may require human intervention to ensure it is aesthetically pleasing, colors are good, tables align, and essential features aren’t incorrect or missing. This may cause delays in the pipeline as human testing is time-consuming.
VALUE IS THE END GAME
Once the application is installed and multiple
instances are in production, it’s tested again to ensure it auto-scales. Techniques like A/B
stack, Blue/Green and Canary deployments can be used to test a new version along with the old
application version and cutover to the new version, remove the old version, to ensure no service downtime can also
be more easily utilized. However, the tires still need regular kicking to ensure it works as it should, particularly as developers turn out multiple iterations over time.
The goal is for developers to be constantly delivering high-value software. Ideally, that should include continuous “womb-to-tomb” development approach until the application is of no further use or has no end users, and is decommissioned. That would be one answer to the problem of orphan legacy applications on which the government now spends so much money and time.
ACCEPT THE BUILD
When the build and unit testing is completed successfully, the CI/CD server
makes a deployment request to the Enterprise Orchestration Server to build a virtual acceptance
stage server. This server includes the necessary application run times, operating system version and libraries, and then deploys the application.
Once the Enterprise Orchestration Server completes the provisioning of the acceptance server and deployment of the application, the CI/CD server can initiate it to build a test client server using test software obtained from the artifact repository.
The CI/CD server can initiate the integration tests on the application, thus ensuring the application code and its infrastructure are correct and repeatable.
ON TO PRODUCTION
After passing these quality assurance tests, the application is almost ready for production release. Back at the ranch, however, performance and load testing are ongoing:
The application still needs to be checked against environments that emulate multiple users and scale to determine how the application and its infrastructure react to various levels of traffic.
If that testing doesn’t map to expectations, if the infrastructure playbook or the application code is wrong for the user environment, it should be fixed at source to ensure all changes are captured in the SCM.
Everything that moves into acceptance and beyond should be immutable to eliminate environmental defects and workarounds. The goal is to ensure that each build
is correct and tested as much as possible when it gets to production. For that reason, rollbacks to the latest working version of the build are available if defects are detected during production deployment.
For more information, visit: www.dlt.com