Pixi-CRS goes to the Cloud - Part 6 : Summary and Comparison

This is the last blog post of the "Pixi-CRS goes to the Cloud" series.
In this blog post, we will sum up and compare the five Pixi-CRS pipelines we built: CircleCI, Amazon Web Services, Azure, Google Cloud Platform and GitHub Actions.

OWASP DevSlop's goal was to migrate Pixi-CRS to the cloud and we've been successful!

Comparison of the 5 Pixi-CRS Pipelines

-	CircleCI	AWS	Azure	GCP	GitHub Actions
Tool Name	Jobs	CodeBuild	Azure DevOps Pipelines	Cloud Build	Actions
Code File	.circleci/config.yml	buildspec.yml	azure-pipelines.yml	cloudbuild.yaml	.github/workflows/pixi-crs-ci.yml
Start of CRS	docker run	docker-compose up --env-file	docker-compose with FileArgs	docker-compose up --env-file	docker-compose up --env-file
Start of Pixi	docker-compose up	docker-compose up	docker-compose	docker-compose up	docker-compose up
CRS Tuning	docker cp	volumes	volumes	volumes	volumes
Testcafe Tests	docker run testcafe/testcafe	npm install testcafe	docker run testcafe/testcafe	docker run testcafe/testcafe	docker run testcafe/testcafe
Test Endpoint Pixi	http://172.17.0.1:8000/	http://localhost:8000/	http://172.17.0.1:8000/	http://172.17.0.1:8000/	http://172.17.0.1:8000/
Test Endpoint CRS	http://172.17.0.2/	http://localhost/	http://172.17.0.1:8080/	http://172.17.0.1:8080/	http://172.17.0.1:8080/
Pipeline Trigger	GitHub Webhook	Set "Primary source webhook events"	trigger: -master in azure-pipelines.yml	Set "trigger"	on: [push, pull_request] in .github/workflows/pixi-crs-ci.yml

In the table above, I compare cloud providers and pure CI tools. This comparison is a little problematic because the cloud providers and CI tools do not have quite the same strengths. CI tools are strongly designed for the continuous integration part and the cloud providers offer a lot around it.
However, while writing the code, I had more trouble with some pipelines than other pipelines:

The pure CI tool CircleCI is easy to configure and the code is easy to read. The only drawback was that I had to mount volumes in a container with a workaround.
The AWS buildspec.yml is also easy to configure and easy to read. Of all three cloud providers, this was the easiest code to write for me. Here I couldn't mount any volumes either, and I had to install Testcafe instead of using it as a Docker container.
The Azure Pipeline azure-pipelines.yml and the GCP cloudbuild.yaml was a bit more tricky to write. This code is less intuitive and you have to look up the options.
The GitHub actions were easier again and I was able to use large parts of the CI code from CircleCI and AWS.

This is a personal comparison and maybe I am not familiar with all of the possibilities that the code offers. And maybe more options are now possible than when I wrote the pipeline code.

What I learned

For me, it was super fun to get to know the three cloud providers and GitHub Actions and to learn how to write pipeline code for all of them.

I know there are different ways to implement solutions. I also wanted to try them out. Besides the fact that I sometimes needed to search for another option to implement a pipeline step, I enjoyed trying out different approaches. So, the pipelines can differ.
Maybe there are better ways to implement something. Pull Requests and contributions against Pixi-CRS or feedback are always very welcome :-)

Thank you OWASP DevSlop for giving me the opportunity to play with these cloud providers and to learn new stuff!
I hope that the pipelines provided and idea behind them, namely to test a WAF early in the delivery pipeline, or the provided code, will help some of you!