DevOps @ OpenShift Online

Editor's Notes

• #3: From OpenShift Origin to OpenShift Online, we will discuss the processes and environments used to make this all possible. We will show how OpenShift Online consumed OpenShift Origin to offer the hosted Online version that users can utilize for free in the cloud. We will also talk about how OpenShift Online contributes back to OpenShift Origin as the main contributor to Origin. Finally, and for a large portion of the presentation we will be talking about how all this comes together in a walk through of the environments used for OpenShift Online DevOps as well as the process by which we bring code to production.
• #4: Effectively this means that the Dev Team and Ops Team work hand in hand instead of being disjoint teams who's only interaction is post software release. <Click for next slide>
• #5: OpenShift Origin is the upstream location of code and is where rapid development happens. Both OpenShift Enterprise and OpenShift Online pull from the Origin Code base and any changes that make their way into either the OpenShift Online or Enterprise code base must hit upstream first or in parallel. OpenShift Online follows Origin much more closely than Enterprise as Enterprise gets the full treatment of fit and finish to become a stable code base in which to deliver as a product to customers. <next slide>
• #6: A DevEnv is a self contained single instance of OpenShift used for testing and development of the platform.. <next slide>
• #7: Jenkins is used to orchestrate the creation of a development environment. We create a base AMI at certain intervals so that the image that is used to create the DevEnv AMI is always kept up to date with the latest OS updates. From there a Devenv is launched and code is either pulled from master on git or from an rpm package set in our internal rpm build environment in order to simulate a deployment. Once DevEnvs are created they are registered as AMIs that instances can be launched from for DevOps and QA team members to work with, code, test, etc. <next slide>
• #8: In order for a DevEnv to be created, it must be built either from the latest set of code out on master from GitHub or from a rpm package set, then it runs through a series of Cucumber and Rake test cases. In the event the image passes, it becomes registered as the new DevEnv AMI which devs can launch to work off of. The normal process is to build from master on GitHub, this happens many times a day and the process is that a merge task in Jenkins from the OpenShift-bot for GitHub will schedule a build, Jenkins will clone from master, launch an instance of our BaseAMI, sync the github repos to the DevEnv as well as automate laying out the files in a structure that the test case scripts need them in, build the RPMs from source, perform an installation and configuration of OpenShift from the RPM set, and run the test cases (reporting the results back to jenkins along with log collection and archival on Jenkins for the previous 50 builds). <next slide>
• #9: The way code makes it from developers into master is that they will fork Origin's master code base, set Origin to the git upstream origin code repository, spawn a devenv, code in their local git repo, commit code and run the origin-dev-tools utils to sync that code to the DevEnv which will spawn the RPM builds and installation, then using those origin-dev-tools utils can run the test suite. Once a change, patch, or feature has passed the test cases it can then be put into a pull request in GitHub, it should be reviewed by another OpenShift developer and receive a +1 in the comments of the pull then someone with permissions will place a [merge] “tag” in the comments and the OpenShift-bot will start running a set suite on it. The bot will clone master, pull down the patch from the pull request and merge it locally, then spawn a DevEnv and sync this newly merged code to it (remember the sync will build the RPM package set, and run the test cases. Once the test cases pass, the bot will merge the pull request into the master branch. <next slide>
• #10: OpenShift Online DevOps – Code “graduates” from INT to STG and from STG to PROD as a set of RPM packages. Meanwhile on GitHub, development of upstream never stops and no code is allowed into Online that has not been pushed upstream first. Patches to stage are either pushed into master or are pushed to master first and brought from master to stage but upstream of code ALWAYS happens. All environments are currently managed by puppet configuration managment.
• #11: Each of the three environments (INT, STG, PROD) all share a like architecture that mirrors what you see here in the diagram, the scale of each environment is of course different as the INT and STG load are far less than that of PROD but we do duplicate redundancy through out the architecture so that we can test as closely in a 1:1 scenario as possible.
• #12: Thank you very much for your time today. I’m happy to take any final questions that you may have. <end>