Elisabeth Hendrickson on Using PaaS for Continuous Delivery at the Cloud Foundry Summit

July 24, 2014 Paul M. Davis

featured-PaaSContinuousDeliveryDuring a technical breakout session at the Cloud Foundry Summit 2014, Elisabeth Hendrickson, director of quality engineering for Cloud Foundry, explained the value of continuous delivery and how a PaaS like Cloud Foundry can enable automated deployments with zero downtime for users.

Continuous delivery is a software development practice that allows automated software delivery and frequent releases, with little or no manual intervention. Continuous delivery provides the ability to reliably push software updates to users with no downtime. In her talk, Hendrickson explained how automated deployments are a straightforward process using Cloud Foundry.

Hendrickson began her talk with a discussion of continuous integration, the practice of merging all developers’ versions into a single version multiple times a day. “What’s interesting about continuous integration,” she said, “is that that you’ve got a bunch of developers who are contributing stuff, and with ever single contribution, before they check in, they’re doing local merge to make sure that everything’s working well.”

She explained that the challenge of continuous integration isn’t the technical aspect, but rather the culture change it demands. “If you’ve got a bunch of people throwing stuff in,” Hendrickson said, “and they say, ‘it worked on my machine,’ then you’re going to have a problem with your organization.”

Continuous delivery addresses such roadblocks, she explained, as “It means that your software is production-ready from day one. You theoretically could put this thing in production right now; it’s now a business decision whether or not you’re going to.” Developers know that their software updates will work in production, because they are placing them “in something that looks like production all the time.”

For continuous delivery to be successful, three requirements must be met:

  • fully automated testing
  • a continuous integration server that executes those tests and can promote successful deployments
  • a scripted automated deployment mechanism with zero downtime

The final requirement is where Cloud Foundry comes into the picture. “You’re going to go from having a single build to having an entire pipeline with continuous delivery,” she said, “because you’re not going to have a separate phase during which some QA people take over and do a bunch of stuff.” Cloud Foundry includes a number of features that enable automatic deployment while ensuring that working code is consistently being pushed to users. Hendrickson listed some of these key features in her talk:

  • same exact code in a different space
  • the ability to perform blue-green deployment to ensure zero downtime for users, who “won’t even notice that you’ve been upgrading the code from out under them”

Hendrickson offered a real-world use case by demonstrating how Cloud Foundry enables continuous delivery for one of its own applications, docs.cloudfoundry.org. All of the Cloud Foundry docs run as apps, and the developers do continuous integration and continuous deployment. “It’s a great little use case,” she said, “because we’re using our own stuff to deploy something that’s very much in production and that we very much care about.”

Screen Shot 2014-07-22 at 7.04.50 PM

All of the documentation is modular, she explained, with a large number of GitHub repositories. “As soon as a writer checks in a change to any of those modules,” Hendrickson said, “it kicks off three different builds because we have to publish three different versions of our documentation.” They are building an entire documentation set which cannot have broken links, meaning that the build pipeline assembles the static document files, verifies the links, deploys to a staging site for review, and following review, automatically makes the updates live on the Cloud Foundry site.

“We’re updating our documentation sites at least once a week,” Hendrickson said. “Once a week sounds like it’s not continuous, but it is, because we could do it at a moment’s notice.”

Learn more:

About the Author

Biography

More Content by Paul M. Davis
Previous
Case Study: How Pivotal Network Does Zero Downtime Deployment on Cloud Foundry
Case Study: How Pivotal Network Does Zero Downtime Deployment on Cloud Foundry

At the end of last quarter, Pivotal Network (the platform for evaluating Pivotal Software) came out of a th...

Next
Tech Talk: Sourcegraph – A large-scale code search engine in Go
Tech Talk: Sourcegraph – A large-scale code search engine in Go

Unit tests are essential to maintaining code quality, especially as the complexity of an application increa...

Enter curious. Exit smarter.

Register Now