Over the last few years CI/CD (Continuous Integration/Continuous Deployment) thanks to new technologies has become a lot easier. It should no longer be a major thorn in the side of developers. Many are moving to cloud platforms which has CI/CD built-in (Azure DevOps for example), others are using Kubernetes which clearly reduces a lot of the complexity around CI/CD. Still at many organizations I see Jenkins or other complex and often homegrown tooling. I certainly recognize this tooling was needed but in 2019 there are better, more streamlined options. Now I get it, our butler Jenkins has served us well, for many years, he has become part of our family. But just like the famous Butler, Alfred from Batman, he has gotten old and likely it is time to look into retirement.
In this article we will discuss and demonstrate how to use Ansible Tower and GitHub for CI/CD.
A video presentation and demonstration is available at following URL: https://youtu.be/lyk-CRVXs8I
Microsoft has wasted little time getting value out of their GitHub acquisition. They have now fully integrated GitHub and authentication into an already powerful DevOps platform called “Azure DevOps”. I have until this moment had zero enjoyment, setting up and maintaining CI/CD tooling usually involving some form of our dear butler, Jenkins. Nothing wrong with our old Jenkins but let’s face it, he is just overhead at this point, better to just put him to rest, he has earned it.
Azure DevOps has the following value:
- It’s in the cloud, consumed as-a-service
- Completely Integrated with GitHub
- It is free
- Authentication using GitHub user
- Don’t need to use it with Azure
- Supports basically every language, I am doing CI/CD with Go
- Simple yaml to configure no Groovy/DML Jenkins horror
- Yaml pipeline files auto-generated for your language (just needs minor tweaks)
- Your code is built, unit tests are run, you can do acceptance tests and it is setup in a few minutes
OpenShift Container Platform 3.6 went GA on August 9, 2017. You can read more about the release and new features here. In this article we will setup a standard non-HA environment that is perfect for PoCs or labs. Before we begin, let’s explain OpenShift for those that may be starting their OpenShift journey today. OpenShift is a complete container application build + run-time platform built on Kubernetes (Container Orchestration) and Docker (Container Packaging Format). Organizations looking to adopt containerization for their applications need of course a lot more than just technology, (Kubernetes and Docker), they need a real platform. OpenShift provides a service catalog for containerized applications, huge selection of already certified application runtimes + xPaaS services, a method for building containerized applications (source to image), centralized application logging, metrics, autoscaling, application deployments (Blue-Green, A/B, Canary, Rolling), integrated Jenkins CI/CD pipelines, integrated docker registry, load balancing / routes to containerized apps, multi-tenant SDN, security features (SELinux, secrets, security context), management tooling supporting multiple OpenShift environments (CloudForms), persistent storage (built-in Container Native Storage), automated deployment tooling based on Ansible and much, much more. OpenShift is a platform that runs on any infrastructure, from bare-metal to virtualization to public cloud (Amazon, Google, Microsoft), providing portability across cloud infrastructure for containerized applications. All of these things together is what truly enables organizations to move to DevOps, increase application release cycles, speed up innovation cycles, scale efficiently, gain independence from infrastructure providers and deliver new capabilities faster with more reliability to their customers.
One of the hardest things companies struggle with today is release management. Of course many methodologies and even more tools or technologies exist, but how do we bring everything together and work across functional boundaries of an organization? A product release involves everyone in the company not just a single team. Many companies struggle with this and the result is a much slower innovation cycle. In the past this used to be something that at least wasn’t a deal breaker. Unfortunately that is no longer the case. Today companies live and die by their ability to not only innovate but release innovation. I would say innovating is the easy part, the ability to provide those innovations in a controlled fashion through products and services is the real challenge.
OpenShift Enterprise v3 by Red Hat is about building and running next-gen applications. If we look around, we have seen startups in virtually every market segment, turning the competitive landscape upside down. Startup companies like NetFlix, Spotify and Uber have literally pushed the incumbents to the brink of extinction and overtaken entire industries in a very short period of time. How have they been able to rival incumbents 100 times their size? The answer is simple, by bringing innovation to the market faster, much faster. Complacency and overcoming previous successes are very challenging for incumbents. It is much easier for a startup to innovate than an existing company with a degree of legacy. OpenShift v3 will level the playing field and provide organizations the appropriate tooling to rapidly reduce their time-to-market.
OpenShift v3 allows organizations to deliver innovation faster by:
- Maximizing time developers actually spend developing
- Enabling efficient clean hand-offs between Dev & Ops (DevOps)
- Automating development pipelines and continuous integration / delivery
- Increasing speed of innovation through more frequent experimentation
- Providing state-of-the-art enterprise grade container infrastructure
In this article we will look at how to setup an OpenShift lab environment and get started on the journey to faster innovation cycles.
Once upon a time not too long ago, I had a project to transport data in and out of S3 using Java. Things started off rather smoothly. Within about 30 minutes I had my Amazon Web Services (AWS) account active, had the Java SDK pulled into Eclipse through Maven and was testing my first AWS S3 API calls. Continue reading