We all crave closure. It’s particularly frustrating when your portion of a task is done, but you’re stuck waiting for another set of people to close out the activity. This is all too familiar in software development, where the output of a short sprint can take months to deploy to production.
When I wrote my first book, I quickly learned that many more people were involved after I had finished the “hard part.” That meant months between the end of writing, and actual publication. I see the same situation play out at many companies where applications are code complete, but it takes weeks or months to get into production. We have to eliminate that delay in order to realize the value of software faster. Cloud Foundry’s cf push command does that.
The Six Major Issues Facing Continuous Deployment
What goes into getting code into production? A lot. Besides the many individual steps that we will talk about below, there are several cross-cutting concerns that we all worry about:
- Hardened, consistent hosts. What’s underneath your app? Is it a dusty container image or a virtual machine that hasn’t been patched for a few months? How is each operating system handled? Companies invest a lot in operating system management, attempting to streamline deployments while maintaining a base level of security.
- Minimizing manual activities. Enterprise IT is dominated by ticket-based request systems. The resulting delays cause code to pile up. How can we minimize these delays without increasing our risk? How do we get rid of a “monthly maintenance window” for updates and push changes to hardware or software at any time? What do we do about the different activities based on all the runtimes and services in use?
- Addressing compliance and audit needs. Most large enterprises (and plenty of small to medium sized companies) also work under the shadow of regulation or compliance. The maze of protocol and policy is one of the leading sources of deployment delays, and it isn’t easy to navigate the paths that guard production environments. How can teams prove that they are keeping proper audit logs and minimizing access to sensitive systems?
- Stale references and records. We’re shipping more services to more places, but how do we keep track of what is where, and ensure that networks have the latest routes? Classic configuration management databases and manually configured load balancers can’t keep up.
- Proper Credential management. Who has access to what? How many people need master passwords to deploy your applications?
- Lowering the cost of post-deploy management. When you ship code, that’s just the beginning of the app lifecycle. How does the application scale? What’s the right way to push updates? How is component failure handled?
Automation: 45 Second Versus 15+ Day Deployments
Let’s talk about the time it takes to get code into production. I’ve spent years in enterprise IT, and now I spend time hearing from companies who are still stuck slogging through each deployment. The visual below compares deployment timelines and activities between the best case for traditional systems and the normal conditions for a platform like Pivotal Cloud Foundry. For the manual duration, I did not account for the untold days that requests sit idle in work queues or are subjected to endless back-and-forth exchanges between project teams and operations teams.
As you can see, a cf push command takes seconds while the manual approach takes weeks or even months.
This is possible, in part, because of frontloaded activities that happen when you set up Pivotal Cloud Foundry in the first place. The platform itself takes care of underlying security patching, OS management, buildpack caching, and more. It is all standardized and automated. These activities do not need to be repeated by every team, for every app.
You can review details of the amazing stuff that cf push does in our product documentation. The most important thing? cf push contains lots of intelligent automation—choosing the best container host, retrieving items from cache, cleaning up after itself, and much more. The model abstracts away from the underlying architecture and establishes a common deployment process regardless of what language or runtime your app depends on. That’s huge.
When I push a Java application to Pivotal Cloud Foundry, you can see all the activities in action:
For those that want to take this whole process a step farther, you can also take advantage of what cf push does from within a completely automated deployment process too. Continuous integration and deployment tools can use Pivotal Cloud Foundry APIs and tools to get all the predictability and power of cf push, without actually requiring you to type it into a console!
It doesn’t matter if you already have a container orchestration system or configuration management tool in place. If the entire pipeline isn’t optimized for delivery, clogs along the way will drive you crazy and waste both time and money. Pivotal Cloud Foundry takes care of the many tricky and error-prone deployment activities. This way, you can spend more time building and continuously delivering great apps.
Finish software sprints. Quit waiting on the code complete to go live process. Get code into production faster and reduce business cycle time. Optimize resources. Get closure.
Want to try out cf push? Sign up for a free trial for Pivotal Cloud Foundry on Pivotal Web Services today.
Learning More At SpringOne Platform:
The biggest, best cloud native conference is coming up in just a couple weeks. SpringOne Platform, in Las Vegas, will run from August 1st to 4th. Check out our top picks for sessions in last week’s podcast, hosted by Coté and myself. If you haven’t registered yet, use the code pivotal-seroter-300 to get $300!
About the Author
Follow on Twitter More Content by Richard Seroter
