How to use Everything as Code to create a shared language between Product and Platform teams driven by Ansible Tower and Self Service models

http://www.youtube.com/watch?v=ySe1jCSpb4I

Disclaimer: the high-level architecture solution and the related demo code is an opinionated implementation to solve the problem described here. The author believes that DevOps is not about tools and frameworks, but a mindset and cultural change for teams. This is an implementation that aims to help a team on the DevOps journey of increasing shared understanding within traditional Development and Operation teams.

There are some challenges while adopting a PaaS Platform like OpenShift in an organization. Traditional IT teams have operated in silos where responsibilities for different parts of the Product lifecycle were distributed to different teams, for example, a development team and a release or production team. The teams' domain of knowledge is, traditionally, limited to the activities they perform for their part of the chain of work and communication between these teams lacked flow or was done using ticketing systems that increase handoffs.

There are some reasons why Organizations are adopting/moving to PaaS and Microservices. Increasing Product Team autonomy and agility are some reasons. Red Hat’s OpenShift product and containers, in general, are great solutions to achieve this speed (by providing the Developer Teams with the freedom to build, test and deploy their code faster). Tools alone don’t make you “DevOps”, there is still a cultural change required to fully adopt these technologies and many organizations struggle with this process when scaling to multiple Teams and the time to move from Dev to Production comes.

The goal of this article is to:

• Show how we can use different Red Hat technologies together such as Ansible, Ansible Tower and OpenShift to enable different teams to work as a large long-lived cross-functional Product Team.
• Help to break the existing walls between traditional IT teams, putting a shared language and a shared framework between these teams, so responsibility for the whole Product lifecycle is shared between all the members of the team.

One of the things we do in the Red Hat Open Innovation Labs is to help Customer Teams to transform themselves through our Residencies. We use Agile as part of the Residency process and use different practices and tools as described here. This post is based on the solutions we have already implemented at multiple Customers demonstrating the “Everything as Code” practice.

As previously described, a typical team moving to a DevOps model while adopting PaaS and Containers is one formed by Development and Operations teams. Development is focused on writing the application code, Operations is focused on managing the platform and at the same time supporting the Development team to build and deploy their code onto the Platform. The issues arise when Operations have no knowledge about how the code has been built or how the application components interact. Supporting these teams at scale becomes a nightmare and the Platform that was chosen to gain agility often ends up having the existing rules used to manage IT applied to it, resulting in an underused platform which is an inhibitor for Agile development.

The following diagram shows one solution to this problem. Using Ansible, Ansible Tower and OpenShift we can develop a framework based on a Self-Service model to put a shared deployment language between product teams and those that provide the platform, this shared language is based on how to build and deploy objects into the platform, which increases shared understanding.

Each bullet point represents a stage in the system. On the first stage (1)(2), a Developer uses Ansible Tower frontend (a custom frontend could be created which interacts with Tower via an API) to self-request the onboarding of the product team and their application/services(s) into the platform. Ansible Tower handles that information and will execute a Workflow Job (3) onboarding the user into the system, creating all the required objects as described here and report back to the user via email.

As part of the Workflow, a GIT repository will be initialized (4), that will include the structure to manage both application source code, OpenShift objects and the Jenkins configuration represented in a ‘Jenkinsfile’ as code. The initial OpenShift configuration created includes 4 different OpenShift projects (5), the ‘CI’ project that will include the Jenkins deployment for the application CI/CD process, and 3 additional projects that will be used for image promotion driven by the end to end Jenkins Pipeline previously created.

A custom Hook will be configured as well into the GIT repository, that will trigger the Jenkins pipeline on every code commit (6). This means that on every change committed to GIT by the Developer Team, the Jenkins Pipeline will not only build, test and deploy the application but also will modify/create any existing OpenShift object defined as code in the GIT repository. As part of the sample code you can see how is this achieved using a Framework developed by the Red Hat CoPs called OpenShift Applier we use at Red Hat Open Innovation Labs with every customer during our Residencies.

From now on, the GIT repository will be the only entrypoint for the Development Team (7). This will add 2 main advantages:

• Both Devs and Ops have now a shared framework and shared language on the objects (defined as code as we can see here) that are deployed into the Cluster - increasing shared understanding from both sides
• Every single object deployed into the Cluster including the build Pipeline is now represented as code in a GIT repository - adding the capability to recreate all the content from scratch in case of Cluster failure or recreate objects in a different Cluster for testing or any other purpose with the only effort of changing the destination OpenShift API.

Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn