Selenium SimplifiedToday, 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. [youtube_video id="srbXp0SdJfI"] What we are going to see in the VideoIn 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 WorksThis 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 CodeDeployThe 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 ImageThe 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 CodeAlthough 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.
