Modern continuous integration/continuous delivery (CI/CD) pipeline for traditional provisioning: Your questions answered (Part 1)

During a recent webinar titled, “Modern continuous integration/continuous delivery (CI/CD) pipeline for traditional provisioning,” we received a lot of interest and many questions regarding the topic. Some of the questions were coming in at a very rapid rate and we were not able to address them all. As a followup to our webinar, we have decided to put the answers to those questions into this blog post. The questions are listed below. As always, if your organization is in need of assistance with services that pertain to this webinar, please reach out and contact your Red Hat sales team:

NOTE: the below questions have been paraphrased and ordered for flow from the list in the webinar. Additionally, similar questions have been merged together.

Is the CD on CI/CD Continuous Delivery or Continuous Deployment per se? Or is it actually both?

As CI/CD relates to automated provisioning processes, I believe the answer will always be an “it depends”. It depends on a lot of factors, mainly what the business needs of an organization are. The business needs should drive the technology, and in this case would it make the most sense to have a continuous delivery process which implements manual intervention via code reviews? Or would it make the most sense to deploy to an operational environment without any human intervention whatsoever? That being said, when we’ve implemented this at other customers, we generally see it being one or the other, but not usually both at the same time. In the case of the demo, we used a continuous delivery methodology to show how we are delivering code following manual/automated testing and making it ready to be delivered into an operational environment.

Our developers feel they leverage a lot of products and don’t end up writing a significant amount of code. Because of this, they don’t feel they would benefit from unit testing. Any advice?

Methodologies such as unit testing and CI/CD are meant to improve the reliability of code. If you are writing any amount of code that needs to be reliable, you should consider writing unit tests and putting together a CI/CD pipeline. Over time it will become more and more valuable. Code bases almost always grow in size over time. The sooner you start writing your unit tests, the better. Specifically, unit tests help with the maintenance of the code. They help to ensure that the functionality of your methods is maintained when code changes are made. This makes it easier for other developers to work with your code and ensures the functionality of the program as a whole. It is much less painful to write the unit tests as you go rather than go back and try to create them months, or even years, later. 

What are the alternatives to using Jenkins as a CI/CD automation platform?

There are several standard alternatives that we’ve seen including Travis CI (for GitHub) and GitLab CI (for GitLab). There are many more available as well, some which are publicly hosted Software-as-a-Service (SaaS) offerings and some which rely on managed infrastructure provided by your organization, such as Jenkins. 

Ultimately, our choice to use Jenkins was based on a few factors:

1. Experience and commonality of the product: we have seen it used in many different deployments as it seems to be a very common industry standard.
2. Dedicated infrastructure for testing: because we are testing our provisioning process, we need a separate, dedicated environment similar to production to test our code in. This would have been very difficult to find in a SaaS type of offering, so it made sense to host our on-premise CI tool for this very purpose.

Could I use Ansible Tower instead of Jenkins as the CI/CD automation platform?

Yes. There are various ways to go about using Ansible Tower instead of Jenkins. There is a good blog post which covers this topic at https://keithtenzer.com/2019/06/24/ci-cd-with-ansible-tower-and-github/. I think the key item to be aware of is ensuring that any part of the setup covered in the blog post is communicated to Red Hat support, so you can ensure that any configuration applied to your Ansible Tower infrastructure will not void your support contract with Red Hat.

Could I use AWX or Ansible Engine instead of Tower?

Yes. AWX and Tower provide you an API that Ansible Engine (previously called Ansible Core) does not. Tower and Engine products will be backed by Red Hat support whereas AWX is not, as it is the upstream version of Tower and is only community supported. 

Is Jenkins open source?

Yes. Jenkins is a currently maintained, open source project managed on GitHub at https://github.com/jenkinsci/jenkins.

What editor did you use for your code in the demo? What are the options that are available for me to use for development of my codebase?

The editor being used in the demo was Visual Studio Code. Visual Studio Code is an open source editor from Microsoft that is available for Linux, Mac, and Windows. Any editor which can integrate with Git, including vim, is also a perfectly supportable editor. We are only using the editor to create branches, edit the code, and push to the Git repository. Other examples that we commonly use are Atom, Rubymine, vim, CodeReady Workspaces and Sublime.

In a continuous delivery model, what are the touchpoints where the testing (automated and manual) is done as code progresses to production?

In this example, the automated testing occurs whenever there is a merge. The merge triggers a build in Jenkins which performs the automated testing. The manual testing occurred in our QA branch during User Acceptance Testing. Once the code has passed the initial phases of testing and validation, you are ready to let users test out the feature. Jenkins is a very flexible tool and offers other triggers in addition to a merge. For example, you could also trigger automation based off of a commit or a tag as well. The process shown above might not work for all organizations; rather it was to display a small sample size, which we commonly see, and what could be done. Because of this, it will take proper planning and a well thought out process to figure out what’s right for your business goals.

Is there a specific software defined lifecycle environment process that I need to be using? Do I need to use three distinct environments (e.g. development, quality assurance, and production) as shown in the webinar?

The diagram referenced in the webinar was just an example. You may not need all of the environments shown. At a minimum, you need two environments so that you can keep your production code isolated. Production should only be for working code that has been tested.

What code review is done prior to delivery to production?

In our previous webinar demo, we used a code review process that was implemented upon the initiation of a merge request. In this case, it would be a manual review of any of the changes that were being implemented prior to initiating an automated build via webhook to Jenkins. Organizations which have more formalized and mature testing processes might not necessarily need a manual review in place and may implement a continuous deployment model instead, where the code is deployed to production as soon as all automated tests pass.

Could you use JIRA or Trello at any point in the process?

We did not use JIRA or Trello in our setup, however it should be possible to configure JIRA and Trello to trigger Jenkins builds with appropriate plugins or integrations on their respective products enabled. We also believe that JIRA or Trello could be a key in enforcing agile concepts such as creating and managing short sprints for code changes for infrastructure-as-code processes.