by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : May 2016
For more information, visit: www.dlt.com 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. 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. 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. 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. 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. Infographic-DLTRedHat-GCN-23184.indd 5 4/7/16 8:26 AM
March and April 2016
June and July 2016