The Next Wave of CI/CD - Visual CI/CD Process Design and Automation

Continuous integration (CI) and continuous delivery (CD) are a set of best practices designed to enable development teams to create, modify, improve, and deliver product changes more frequently and with less errors. The entire process is usually called the CI/CD pipeline. 

Testing as part of Continuous Integration (CI) and Continuous Delivery (CD)

One of the most important parts of CI/CD is testing.  Testing also needs to be continuous by definition.  Remember, our concern is making sure we deliver quality applications to our stakeholders.  Continuous testing will consist of running automated regressions, functional tests, unit tests, and performance tests.  These tests need to be executed as part of the CI/CD pipeline.

CI/CD tools such as Jenkins, CircleCI, AWS CodeBuild, Travis CI, Atlassian Bamboo, or others are the tools of choice today for CI/CD.  All allow DevOps engineers to incorporate automated testing.   Additionally, services like SauceLabs allow for CI/CD to be run at high scale and with enterprise level SLAs.  And there are lots of other innovative tools that should be in your testing quiver – tools like scriptworks.io for using a low-code approach to creating your Selenium scripts.

However, today, I want to talk about taking CI/CD automation to the next level by introducing visual process design into your CI/CD toolkit mix. WARNING – Like any technology, this is not for everyone and not for every situation.  For many of you, this will be overkill and you may scratch your heads thinking “why do I need this.”  You may not need it.

What type of Projects should use Visual CI/CD?

So, who should be interested in adding visual CI/CD process Automation to their current CI/CD process?  Here are some of the characteristics to look out for to see if your software project should use visual process automation as an integration/extension of your CI/CD tooling:   

• Multi-tenancy – You are running a multi-tenant SaaS application
• Stakeholder participation – You have customers or partners that need to participate in the process of designing and monitoring code quality and delivery
• Customization – Your application allows for customers to customize the application, and as a result your Functional Selenium tests will tend to grow and change frequently (in my humble opinion, this may be the biggest reason for using visual CI/CD process design).
• Manual Approval Steps – You may need manual approval steps for certain types of tenant updates, ISO and regulatory compliance, or because of stipulations in customer contracts
• Automated Alerts and Roll-back rules – Stakeholders and customers may require timely alerts because of security protocols that they follow or that their customers require them to follow 
• Collaboration – More and more often CI/CD is becoming a business critical function and not just a developer led initiative.  As such, non-technical stakeholders will want to understand the process and will need to collaborate. 
• Complex Supply Chains – For software being built across teams and independent companies, more visual auditing will be needed.
• Parallel Test Execution – Larger projects need to run Selenium tests in parallel in order to be able to run testing more quickly and efficiently

Selenium Simplified

Today, we are going to walk through a live example of how to integrate visual process automation for your CI/CD.  We have built a robust and fully automated process using ProcessMaker, a next generation process automation technology.  We think you will see that this gives us an enormous level of added flexibility, visibility, and efficiency to the typical way that  QA  and  CloudOps  interact  to  perform  automated testing and  run CI/CD pipelines.  As stated previously, this solution is aimed at engineering teams that need to address more complex testing and release deployment scenarios.

In this example our  process  integrates with various AWS CI/CD related services (CodePipeline, CodeCommit, CodeDeploy, and custom Lambda functions), Github, and  Selenium.   In your case, you might choose to use different CI/CD tooling like the ones mentioned above.  You can check out the overview video of the ProcessMaker powered Automated QA test suite here.

What we are going to see in the Video

In our sample application, we have built a visual CI/CD pipeline to test an enterprise multi-tenant application.  This sample was built for a large ERP company that needed to collaborate with numerous suppliers.  Additionally, the application could be customized by customers meaning that for each upgrade, not only did the base application needed to be tested, but customers also would need to be able to store selenium tests in their own Git repositories to test prior to deploying upgrades of the base software.  Additionally, some customers might be on public clouds with fixed time frame provisions while others might be on private clouds which require a manual consent from the customer after they have been given a specified amount of time to review any anomalies from their local test cases.  

So, as you can see, in this case there are a number of reasons why a visual process can greatly enhance the traditional usage of a CI/CD suite.

How the Process Works

This process is started from a code commit that happens in AWS CodeCommit.  This triggers AWS CodePipeline to make a call to the ProcessMaker API to start the process. ProcessMaker then inspects the CodeCommit information to know what functional Selenium tests need to be run and calls the  appropriate  Github repository or repositories to load the correct version of test suites to run. 

Selenium test suites are then run in parallel, all managed by the ProcessMaker workflow engine. The beauty here is that ProcessMaker can handle truly massive parallelization of tests in the cloud.  This can be to run both the orchestration and the execution, or perhaps just the orchestration (when integrated with something like the Sauce Labs API fo execution and additional reporting).

Using Business Rules to Evaluate Test Results before moving to CodeDeploy

The test responses are passed back to ProcessMaker and stored in the appropriate ProcessMaker object. This object is then evaluated by ProcessMaker business rules to see if any of the tests failed.  If some of the tests failed it will alert the appropriate people and it will wait to be run again.  If everything passes, then ProcessMaker will make a call back out to AWS in order to deploy the code into production.

This  process is a fully automated process which does not require any human interaction.  However, because the process is designed visually and is not hard coded, the process can be changed easily and visually.  In this way, all interested parties can see and audit the process.  So, as we mentioned earlier, if a particular customer requires a human approval step (or multiple steps) before going to the code deploy phase, we can easily run that based on a simple business rule.  Others may need to pull from various github (or other) repositories that are both public and private and maintained by different parties.

Executing tests in a Custom Docker Image

The tests that are pulled from GitHub, in this example, are written in Python using script tasks and a custom Docker image in ProcessMaker to run Selenium tests against that target environment.  ProcessMaker allows QA teams to develop scripts in any programming language to call selenium tests and execute them in independent Docker containers.  These Docker containers can even load the language plus any additional libraries or SDKs as needed.

Why even Developers love Low Code

Although CI/CD was invented by developers for developers, its importance is quickly moving beyond the backoffice.  As such, more and more stakeholders need to understand what is happening.  Legal and Compliance are now getting into the picture which means that liability, indemnification, certification, and much more are now affecting the responsibility with which CI/CD runs.   As such, it is a natural evolution of CI/CD that some level of visual low-code/no-code tooling is now required.  The truth is that as long as the no-code visual orchestrated workflow allows developers to use their favorite tools (Docker, Kubernetes, Selenium, Git, etc.) then we have seen that developers love the extra tooling.

If you would like to learn more about running visual CI/CD to extend your current process, please reach out to us at ProcessMaker or check out this video overview.