Article

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

 

June 28, 2016
CI/CD Containers Developer Tools DevOps Kubernetes
Andrew Lee Rubinger
Guest Author
Andrew Lee Rubinger

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.

S,

ALR

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.

    • Set up GitHub OAuth Application
    • Obtain an UltraHook API key
    • Install the ADB and prerequisite projects by following these instructions
    • Start up Openshift via Atomic Developer Bundle and our custom Vagrantfile
      • Create a directory to hold everything
      • e.g. 
        • $ mkdir -p ~/vagrant/adb/openshift && cd $
      • Download the Vagrantfile 
        • $ wget https://raw.githubusercontent.com/redhat-kontinuity/adb-openshift-runtime/master/Vagrantfile
      • Start up the box 
        • $ vagrant up
      • Go get some coffee
        • We’re going to be precaching a lot of Docker images and other big files ahead of time now, so you’re not waiting on pauses during the runtime.  Your network activity will spike every now and again as the chugs along.  Assuming you don’t destroy the vagrant box, this is a one-time initialization.
        • When control is returned to your shell, it’s done.
    • Login to Origin console 
      • https://10.1.2.2:8443/console
      • admin/admin
      • You may have to accept some security exceptions in your browser because you don’t have an SSL Certificate installed
  • Go into the Catapult Project

     

    • Click “Add to Project”
  • Select “Catapult” from the list of Instant Apps in the Catalog
  • Fill in values from above, leaving all other defaults
    • GitHub OAuth Developer Application Client ID
    • GitHub OAuth Developer Application Client Secret
  • Hit “Create” at the bottom of the page
  • Continue to Overview Page for Catapult
  • Wait for deployment to finish and donut to turn deep blue (light blue indicates we’re not quite there yet).
  • Navigate to the running Catapult application
  • Select the “JBoss EAP7 HelloWorld Example” to launch from the dropdown and hit “Submit”
  • We’ll now we forking the example application into your namespace in GitHub, so follow the prompts to give us Catapult access
    • Login
    • Review the requested permissions and authorize access
  • Observe redirect to the project overview page for the newly-created project
  • What happens is:
    • We get 2 services
      • jenkins
      • Jenkins-jnlp
    • Wait for Jenkins to fully start (donut will turn deep blue)
      • Not there yet
      • Ready!
    • Enable metrics
      • Browse  > Pods > Choose Dev Pod > Metrics > Click the Hawkular link and accept the SSL security exception
  • Start a Build
    • Kick a build
      • Browse > Builds > helloworld-pipeline
      • Start Build
  • You may view the build on Jenkins if you’d like

     

    • Login information 
      • admin
      • password
  • The OpenShift Console will visualize the pipeline as it executes
  • Return to the overview page
  • When the build completes, we’ll have a deployment and a running application
  • Let’s visit it
  • Lame; let’s change this.
  • Register UltraHook (only needed for local OpenShift, not Online)
  • Configure your GitHub Webhook
  • Edit the source of your app and run it through the pipeline again
  • When done, bring down the VM 
    • $ vagrant halt
  • When you’re ready to start up again: 
    • $ vagrant up
Last updated: July 26, 2023

Comments