Last week, Matt Wagner and I presented a tutorial (now recorded) on Building Air Framework Plugins. The slides are below:
Our Development team has been busy with plugins as well. In the last week, they’ve released an updated uDeploy plugin for SAP Business Objects; AnthillPro plugins for IBM Rational Team Concert, Oracle WebLogic and NCover, and a uBuild plugin for HP Fortify.
For more on Lean, you should check out of white-paper on Lean Build and Deployment Automation.
For many people, DevOps and infrastructure as code are synonymous. However, I am usually quick to point out the other moving parts that need to be managed. There is more to DevOps than infrastructure as code. Once the infrastructure is in place we need to do something with it. Application deployments, database updates, static content deployments, application configuration, middleware configuration, all of these things come into play after the infrastructure is in place.
There are many excellent applications for managing your infrastructure; tools such as Chef and Puppet obviously come to mind (they are easily the most popular). These types of tools are perfect for making changes across multiple servers, and making sure your infrastructure is in sync. They are also great for taking newly spun up virtual machines and making them identical the other servers in your environment.
Infrastructure is only part of the entire stack, and honestly it is not the most volatile part. New machines requiring infrastructure may be added daily but once the infrastructure is in place it tends to change less often than other components of the stack. For example, the middleware configuration, the applications, and the application configuration all change much more frequently than the infrastructure. Managing these changes is a crucial aspect of DevOps.
In the image above, the lowest layers can be handled by a number of tools. These layers are typically handled by the major IaaS providers (Amazon EC2, Rackspace, and others), which involve provisioning of the servers, as well as the OS and the OS configuration. Another great solution is to use Terraform or uProvision to handle the provisioning. These tools enable companies to build an internal PaaS offering to allow teams to automatically spin up servers and make them available for deployment.
The middleware layers have a handful of solutions for automation. Some companies include this configuration in the base image of their virtual machines. Another popular option is using any of the “infrastructure as code” tools mentioned above. These types of configurations can even be managed as part of your application deployment in an application deployment automation (ADA) tool such as uDeploy.
The application, and the application configuration can change multiple times a day in any continuous delivery environment. Often it may only be the configuration itself (and not the binaries) that need to be deployed. uDeploy is designed to not only automate the deployment of the application but also provide visibility into which versions of changes have been applied and where.
We include a built in package repository, CodeStation, with AnthillPro, uBuild and uDeploy. They also integrate with third party repos. We place much emphasis on this capability because it is critical for safety, governance and audit.
To explain this, let’s first look at a simplified build and release lifecycle:
Developers submit their work to a source control system. A build is generated from that source and any dependency libraries retrieved by a tool like Maven or CodeStation. That build is submitted to test environments and certified. Finally, it is sent to production.
The following questions are important to be able to answer:
To be able to answer 1 and 2, you need an inventory of what version of something is in an environment or at least logging that indicates the version number. But to truly know that what is in production is what was tested, you have to ensure that not just are the file names the same, but that the exact same files were moved into each environment.
In order to know and prove that the files are the same, one must validate that they are bit-for-bit identical by comparing digital signatures or hashes at deployment time. It helps to actually have the original file around in a tamper resistant location. A good package repository, like the one in uDeploy, will provide that location, the automatic signature generation at build time, and the automatic verification so that you know that what is in production is exactly what was built from known source, and tested in the prior environments.
For more information on package repositories, view our on-demand best practices lesson: 'The Role of Binary Repositories in SCM'
Those who attended the DevOps: IT’s Automation Revolution webcast last week (recording here), won’t be surprised by my favorite slide from Glenn O’Donnell’s portion of the presentation. He discussed the challenge of moving a complex application through environments, and the likelihood of “droping the ball” and missing a piece when you go to production.
To address that challenge, Glenn suggested that you create a package containing all the components and make that the granularity for deployment. With all the components tied together, you can’t forget a piece or deploy versions that haven’t been tested together to production.
A "Package" ties versions of various components into a version of the application.
At UrbanCode, we love this approach. After a few years of helping AnthillPro customers approximate this with the dependency subsystem, we built uDeploy around the concept of an application model, and a Snapshot Deployment. The Snapshot in uDeploy is a virtual package, that ties together versions of all the components, without creating a single monolithic binary. It was exciting to see a great analyst explain the rationale for this approach so clearly.
Want to learn more? Check out uDeploy or let us know that you’d like a private demo for your team.
A number of new and updated integrations have rolled out recently, here’s the run-down.
The folks at Atlassian changed up their web services schema. The latest plugin for Jira supports the new Jira web services. You can get it here. If you’re still using the legacy integration rather than the plugin, migrating to Jira 4 is a good time to switch over.
We’re starting to see some adoption of Microsoft Team Foundation Server 2012. Updated integrations for it are now available. They’ll be shipping in uDeploy 4.8. AnthillPro and uBuild integrations are around the corner as well. If you need this integration before the next release, contact support for a patch.
The uDeploy integration for Apache Tomcat has been updated with support for moving over a specialized context.xml with a war file deployment.
This has been available for a little while now, but we should mention that the Jenkins plugin for uDeploy has a couple of enhancements. First, it now supports Jenkins slave builds better. Second, it can be configured to automatically trigger a deployment of the new version in uDeploy.
This integration was expanded to cover ServiceNow’s CMDB offering.
Tell us. When it comes to integrations, we’re all ears. Ok, ears and nimble coding fingers.
Six times a year, there was a party with ice cream. The release effort spanned multiple projects and was a 36 hour, high pressure marathon. Its successful navigation was a major accomplishment to be celebrated.
Aside from getting a new product out the door, the celebration of a release is a “bad smell”. It tells us a lot: The releases are done infrequently. They are hard. There is risk and fear.
Modern approaches like Agile and DevOps encourage smaller, more frequent and less risky releases. In short, releases should be boring. Really, really boring.
Last Friday, we added a search capability to the main website. It’s really nice. We sent out some “nice job” celebratory emails to the team that researched search tools, implemented and styled the new widget. The marketing guys are really excited.
But, we didn’t celebrate the successful deployment or feel relief that it actually worked in production. Of course the deployment worked, it always works. Of course the functionality worked, it worked in the test lab. The test infrastructure and test deployment processes are so similar to the “real” ones, and so automated that there’s no fear. Our uDeploy stats show less than a 1% failure rate over the last six months – and that was in test. No hesitation. Releases happen all the time.
We should celebrate new features and better user experiences for our customers. The process of getting that new feature out the door? Yawn.
If you are throwing release parties, or just relieved every time the release doesn’t go wrong, it’s probably time to look into DevOps techniques and automating your releases. It’s not like the business is going to want to slow down the pace.