Push it Real Good: Continuous Delivery for the people at the push of a button and repo

The Problem

Several months back, our emerging Developer Programs engineering team assembled during the last breaths of Brno’s Czech winter and dedicated a full day towards a deceptively complex task:

Be a user.  Assemble in groups and, using a technology stack of your choosing, conceive of and create an application to be presented to the full team in 6 hours.

Keep in mind that I hold my colleagues in extremely high regard; they’re capable, creative, and experienced.  Surely churning out a greenfield demo application would be a laughable exercise done by lunch affording us the rest of the afternoon to take in local culture (read: Czech beer).

So we started to break down the tasks and assign people to ’em:

  • Bootstrap the application codebase
  • Provision a CI environment to build and test
  • Stand up a deployment environment
  • Hook everything together so we’re all looking at the same thing through the dev cycle

We wanted the same conceptual infrastructure we use in delivering Red Hat products and our open source projects – authoritative systems and Continuous Delivery.

And therein lies the problem.  Of the 6 hours spent on this exercise, I noted that every team spent over four and a half hours getting themselves set up and hacked furiously on their real job – the application – in the final sprints.

But that’s not the real problem.

The real problem is that users, all across the globe, have the problem.

And in this moment, it crystallized that it was now our mission to fix this.

Our industry has given developers wonderful tooling, frameworks, and runtimes. With containers, we even have standardized deployment.  And by the way, we require that you load your own containers onto the boat.

We’re missing a unified, cohesive story which brings applications out of the development environment and into service.

The Mission

We need to empower engineering teams with an intuitive experience to quickly and confidently promote their code from development to production.

And the application is more than just your code; it’s every piece running together:

  • The Codebase
  • The Build Config
  • The Build Environment
  • The Runtime and its resources and configuration

So we rallied around the mission to bring CI/CD to application developers rather than leaving them to set it up themselves.  We set the following design principles:

  • Fail-Fast
    • When things are not working correctly, give feedback as quickly as possible
  • Reproducibility
    • Ensure applications can be built and delivered consistently over time
  • Encourage exploration
    • Dovetail with existing quickstarts to make learning faster and less catastrophic
  • Cloud-enabled
    • Reduce dependency on local development environments and offer production-like environments before the upstream merge
  • Teams are Key
    • Focus on collaboration

Today at DevNation and Red Hat Summit in San Francisco, we unveil as a preview our first step in that direction.  It begins with quickstarts and demos, but it’s a building block to enable much more.

We’re using the best the industry has to offer in bridging an end-to-end solution, including technology built atop:

And the experience, to start, is this.  We’ll:

  • Fork an Example or Demo project into your namespace on GitHub
  • Create an OpenShift project with pipeline to:
    • Build
    • Unit Test
    • Containerize
    • Deploy to Dev
    • Integration Test in Dev (depending upon your project setup)
    • Hook into source control to make the process repeatable

Give it a spin!  I haven’t been as excited over a potential to improve application development productivity since we birthed Arquillian.  And give a shout at @ALRubinger if you’d like to get involved in development, docs or have any other feedback; we’re gonna be building this out — the open source way.


PS – For anyone interested learning how the sausage is made, this exercise took thought leadership and execution from our Fabric8, OpenShift, User Experience design, Developer Programs, and Consulting engineering teams and business units in concert with the enabling upstream projects from the open source community.  My thanks to them all for our having something great to share today.

Try It Yourself

Until we can make this publicly-available on the new OpenShift Online, we’ve got some instructions for you to try the experience at home.

Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.

DevNation is now part of Red Hat Summit.  See www.redhat.com/Summit.  Red Hat Summit is for developers!

For more information about Red Hat OpenShift and other related topics, visit: OpenShift, OpenShift Online.

  • Hardy

    The section “Install the ADB and prerequisite projects by following these instructions” seems OS specific. Most likely Linux/Fedora. This should be explicitly stated and preferably some advice for other OS types.

    Also the following lines seem odd:

    $ sudo dnf install -y ruby-devel vagrant-libvirt @development-tools rpm-build zlib-devel
    $ gem install nokogiri -v ‘1.6.8’

    Why installing a Ruby development environment and why Nokogiri? It should be enough to

    $ sudo dnf install -y vagrant
    $ vagrant plugin install vagrant-service-manager vagrant-sshfs vagrant-libvirt

    Something along these lines.

    • Andrew Lee Rubinger

      Correct; TBH at the moment (and because this is really tech-preview), we’re relying on ADB as the delivery medium for these features, and hence the instructionset comes straight from ADB (with a little flavor mixed in I needed to get this to work with Fedora). The Nokogiri gem installation was a part of that process; if you have a more trimmed one – would love to hear it!

  • Very interesting initiative! As an engineer who works a lot with deployment automation/orchestration and building delivery pipelines for Continuous Delivery, the obvious question is what kind of support exists for automating the steps requiring UI interaction in the article? Is there a CLI or some kind of API available for hooking in to the process programmatically? All in all I think it looks like an interesting solution.

    • Andrew Lee Rubinger

      Great question!

      So the UI you see is a stupid HTML form (likely to be replaced by something more intelligent) which hits an HTTP endpoint to Catapult. So given you have your own repo armed with the requisite inputs (like a Jenkinsfile to define the pipeline, possible some other pieces to describe the OpenShift project to create), you’d call upon the HTTP endpoint, pass in your inputs, and watch it do its thing to your repo.

      We know that for many folks the QuickStart is the entry point, but the immediate questions after that are:

      1) OK, what about a project I create from scratch that I describe?
      2) …and what about one of my existing, brownfield repos?


      • Travis Brown

        Great work! This was my favourite DevNation 2016 presentation.