DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 79 posts at DZone. You can read more from them at their website. View Full User Profile

The DevOps Toolchain

03.29.2013
| 4122 views |
  • submit to reddit

Urbancode’s DevOps toolchain begins with a developer committing code to a source repository. Commit comments can be added so that uBuild will associate the code change to a bug report (Bugzilla, JIRA, Rally, TFS, TeamForge) or a feature story (Rally, PivotalTracker, VersionOne, Rational Team Concert).

uBuild will wake up periodically and build the code projects that have been changed during the latest period. The code changes, the execution of the build, and the output of the build are associated with this unique build. The build is then tested (JUnit, Selenium, HP QualityCenter, Cobertura) and analyzed (PMD, FindBugs, Coverity, CodeSonar, Rational AppScan, FxCop, Clockwork), and the outputs associated with the unique build. If the build, tests, or analysis determine a problem, the development team that owns the project is notified so corrective action can be taken. The entire process is known as Continuous Integration.  All projects in the enterprise that depend on this build can be set to build when changes to dependencies occur, and if a problem is found alerts that team. This is Enterprise Continuous Integration.

If the build passes the tests, the build artifacts can be automatically sent to uDeploy which will version them and automatically deploy them to a development environment for more automatic and manual testing, demonstrations, etc.  Once the development team is satisfied with their application, they can request a deployment to a test environment so the QA team can test. This deployment can have an approval process so it won’t deploy to test until the QA manager is ready for a new version and approves the deployment.

Development and QA teams can deploy the application to lower environments and DevOps teams can promote the application to higher environments. They use the same processes to orchestrate the deployment of software, data, and configuration to application servers (WebSphere, WebLogic, Tomcat, IIS), databases (Oracle, SQLServer, MySQL, DB2), infrastructure (F5), ESBs (Informatica, SharePoint, BizTalk, MQ systems), systems (Linux and Windows utilities). The deployment process can also coordinate with ticketing systems (Remedy, ServiceNow, HP Service Manager) and monitoring tools (Nagios).

For the deployment into production, the Release Manager can reuse an old release plan or create a new one using uRelease.  uRelease allows the release team members to know what to do and who is responsible for doing it.  As the release clock ticks on, the release team updates their activities like creating an outage request, using uDeploy to deploy applications to production, manually testing the deployed application, using uDeploy to rollback to the old version if needed, and sending out end of outage notifications.

The DevOps toolchain manages your applications from code all the way to the hands of your customers.  You develop, we deliver.

Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)