Testing in GitOps: Triggering Test Workflows

Bruno: But first, let us introduce ourselves.

I'm Bruno. I'm the head of the project, Testkube. I've been talking with many testing companies that are, evolving their testing methodologies, and, you know, we work a lot with Kubernetes and and those big enterprises. So we have a lot of knowledge that we would like to share with you today about that.

And now I'll pass over the word to you, Yuliia.

Yuliia: Yeah. Thank you, Bruno. Hi, all. My name is Yuliia. I am based in, Lviv, Ukraine.

I'm a DevOps engineer here in Testkube, and, we are trying to make our Testkube installation for you as smooth as possible.

Yeah. And are working on, integrating it in ArgoCD or in Argo Rollouts. Any tools that you may use that, will ease your deployments help you in your infrastructure.

DEMO: Triggering Test Workflows

Yuliia: Thank you, Bruno. So, as Bruno mentioned, there are many benefits that Testkube can provide when used with Argo. And today we will focus on ArgoCD Post-Sync Hooks and Argo Rollouts.

In the first part of our demo I will demonstrate how we can run a Test Workflow after an application is synchronized successfully. And in the second part we will explore how Testkube can be integrated into Argo Rollouts deployment strategies to help catch unpredictable issues with the application and to ensure that they are functioning as expected.

Before that, I'd like to share a few words on how we can trigger a Test Workflow, before shifting our focus to ArgoCD Post-Sync Hooks. And actually, to start with what that Test Workflow is. So, Test Workflow: this is the manifest where you can define your tests in your Kubernetes cluster. It's very powerful and flexible, and it gives you lots of room for customization, as you may define as many steps as you'd like there. You can provide environmental variables. You can provide, resources requests, and limits.

You can, provide the security context and so on and so forth.

And to read more about what Test Workflow is, how they work, you can, in our documentation page.

Firstly, let's start with the Testkube dashboard.

This is one of the ways how you can trigger, a Test Workflow. So Testkube dashboard, basically, this is the user-facing interface, where you can interact with, our Testkube components. Like, you can create Test Workflows, you can create triggers, webhooks, and so on and so forth.

I'd like to switch to the dashboard to show you how it looks, what we can do there with this Test Workflows, and then, we will move forward from there.

Requirements

Yuliia: This is basically the prerequisites that I'm using in my demonstration. So, my Kubernetes cluster, my Testkube account with the dashboard.

I deploy the Agent, which is the Testkube service that is running on your own infrastructure.

It executes the test, listens to events. And we also need ArgoCD for everything to be synced using the ArgoCD. We have our Test Workflow. They are testing our applications.

And finally, Test Triggers and Post-Sync Hook manifests: they will, basically trigger those Test Workflows.

Testkube Dashboard

Yuliia: I'm using, for the demo, our SaaS solution that is deployed at app.testkube.io. So here I have registered my account.

I have my organization and I have my environment. Environments, basically, this is where you can group your test workflow and everything that you...all the resources that you have for your Testkube. Once you open the dashboard, you will land on this page where you can see the insights, the recent executions. And, well, look through all the insight in details.

Then we will go to the Workflows.

Today we will only work with this page, but later you may explore all the other functionalities that Testkube can provide. I have pre created four workflows for today's demonstration, and let's explore one of them. Let's say the "k6-workflow-success."

So on the first step, we will have the overview.

There we can see the visualization of our workflow: the statistics, the pass-fail ratio, execution duration, and so on and so forth.

Next, we have the executions.

I can see that all my executions are successful. We can find the time of the executions, the duration.

We can choose the time frame, etcetera.

These CLI commands, this is also one of the way how you can run your test workflow, but we will not cover it today. It's basically just using the kubectl tool. And you basically just copy the the command and run it to your terminal and you can create a test workflow, you can list execution, you can delete the test workflow, and so on and so forth. Then we have the CI/CD integration. So these are the snippets of the code on how you can integrate Testkube into your CI/CD pipelines.

And, finally, the settings.

There are many tabs to explore here, but I'll just want to briefly mention that here you may specify any customization you'd like and see the definition of your Test Workflow. Let's just open this one.

This is called the "k6-workflow-success".

What it does, it's a very simple code that basically just sends an HTTP GET request to this URL that I defined here in a config.

That's it. It also accepts environmental variables and the artifacts. This is the password, it uploads the artifacts.

So let's go back to the overview.

Bruno: Artifacts, Yuliia, is, basically, the file that's generated, right, from this test that generates, like, reports or videos or something. And this will go to your pods. Right? And then they it will store it.

Yuliia: Yeah. Yeah. So, for the SaaS solution we store artifacts on our infrastructure.

And in the UI, you basically can go to the execution and find the artifacts here and just to download them.

Bruno: Yeah. Awesome. Yeah.

Or open on the on the browser. It's also possible. Also, we have a SaaS offering, but also fully On-Prem as well. So anyone can just go to Testkube and use Testkube.

Also, it works also in air-gapped, environments. So whatever deployment model people prefer, Testkube can do it for you.

Kubernetes Event Trigger

Yuliia: Let's move to the Kubernetes Event Trigger and Argo Post-Sync Hook. So I will click quickly cover both these points. So, in Testkube, Event Trigger allows you to trigger the execution of a workflow based on the Kubernetes events. For example, when a deployment gets updated or an ingress deleted and so on and so forth. Whenever a resource gets updated in your cluster, be it by ArgoCD or kubectl or any other process, your test workflow will always execute.

You can currently manage event triggers in the Testkube dashboard and using kubectl.

I'd like to demonstrate how event trigger works in our clusters. I would like to continue sharing. Bruno, can you please put me on stage?

Bruno: Yes.

Yuliia: Thank you. And, to start with, I wanted to show you my environment that my Kubernetes environment and all the application that I deployed using ArgoCD. So there are three applications here. The first one is, Testkube Demo. So, this is the Testkube agent that I deployed with my infrastructure. So what is Testkube agent? Testkube agent, this is the service that you install in your Kubernetes infrastructure along with the application that you want to run your test workflows against too.

Testkube Agent executes tests. It listens to Kubernetes events, and the important thing to remember is you always install it on your infrastructure, unlike the Testkube dashboard, our SaaS solution. So you we are connecting here our agent to our dashboard, basically.

The next is the test workflows. So I have deployed the test workflows using the ArgoCD.

You have already seen these test workflows in the dashboard.

I have just created a simple ArgoCD application and synced these test workflows from my git repository.

Good thing about the ArgoCD and Testkube is that when you accidentally delete your task workflow from the cluster in the CLI on the ArgoCD UI, you can sync it back using ArgoCD.

And the last application is basically, the simple NGINX app application that we'll be modifying, and triggering our Test Workflows against too. So I have already deployed a test trigger here, and I will show you the manifest firstly, and then we will update the NGINX deployment and see how this test trigger launched test workflow in our Kubernetes cluster.

So I will move to my--

Bruno: I think can add: the big advantage of having these workflows, you know, ArgoCD, synchronized to your cluster is that, Argo is synchronizing your applications and the tests of those applications.

So you're like doing the both things at the same time is and it's really nice for you to see in easy way what is going to get deployed and how the thing that you just deployed is going to be tested. And both of it is version controlled, which is also, like, really cool.

Yuliia: Yeah. Exactly. Okay. So you're seeing my, repository. Is that correct? Yeah?

Bruno: Yeah.

Yuliia: Alright. Cool. Okay. So, we have this Testkube example repository, which is publicly available, and you can basically access it anytime you'd like. So I had created my examples in this folder. So now I will open this NGINX directory and will show you the test trigger manifest.

So I will, zoom it a little bit.

So this is a very, simple manifest.

What it does, it basically works with the deployment manifest that has these labels, and it's reacting to this event. So, basically, when we modify the deployment with App NGINX labels, the test trigger will execute a test workflow. And what this test workflow is, is the "postman-workflow-smoke-success" that we specified here.

So, basically, that's it. It's a very simple one. We also have here the conditions. This is basically the list of checks from your resource to be sure that it is in the ready state.

So deployment must be progressing and must be available.

And the action is run. It's the only one supported action for now. We allow the concurrentPolicy.

And, yeah, the execution is testworkflow, and the name of the task workflow is "postman-workflow-smoke-success."

So, if we right now update the deployment of our NGINX application so, this is the application. This is a very simple deployment and service. I would like to update the image, then I will push it to my git repo.

Yeah. And, if I go back to my ArgoCD, so this is the NGINX application that we are working on. And let's not WAIT for the ArgoCD to synchronize now. Let's do it right now.

It usually takes some time to sync it. Yeah. And now we see that a new pod is launched with another image. We had the version 1.0. Now we have 2.0.

And now, as the deployment was modified, we can go to our Testkube dashboard and see that this "postman-workflow-smoke-success" was just now executed.

And if we go to the executions, we can see that it just now executed, and it is successful.

Yeah, I think that's it for the Test Triggers, unless Bruno, you wanna add something? Otherwise we can move on to the Post-Sync hook.

Bruno: No. It's really good. And the main value of this Testkube functionality is that you can react to any changes in your cluster. So whenever, instead of setting up steps in your CI/CD, to test, to run any test when anything happens, you can just tell Testkube, "Listen for this event or for this change," and then you want to test. So it's good for Argo because it's when Argo deploys the application, does any changes, Testkube runs the test, or anything changes. But it could be deployment, but can also be a config map, or a secret or many things that happen in your cluster. So it's very reactive and is an easy way to ensure that everything gets tested early, and very often.

Yuliia: Yeah. Thanks. And one thing that can be added is that the Test Triggers: they will execute if your resource is a part of a very big application.

This application sometimes may fail synchronizing or not being initialized correctly, but the test workflow will still execute. So this should be taken into account when working with this Event Trigger.

Argo Post-Sync Hook

Yuliia: Post-Sync Hooks, they are executed by Argo after it has successfully synced resources within applications. Basically, a very simple definition, and this is the perfect fit for your GitOps pipeline.

Yeah. So to demonstrate how the post-sync hook works, we will use the same NGINX application, the same git repo. However, a different manifest which will be a Kubernetes job with the post-sync hook annotation.

And now I will share my screen again.

Bruno, could you please put me--yeah, Thanks. So I'm again into my repo. I'll now close the application. I will close the test trigger and I'll open the post-sync hook.

So, the example is also quite simple.

This is the "kind: job."

Then it has just two annotations, PostSync and HookSucceeded.

HookSucceeded means that, the job will be deleted once it's executed successfully.

What this job does is basically launches the Testkube CLI container image. It accepts a few environmental variables that are passed here as secrets, as these are the sensitive values. So we have here API token, environment ID, organization ID, and root domain. All these values you can find on your dashboard.

Then the job sets the context using the values that you provided and runs basic cURL Test Workflow.

So now I will deploy this Kubernetes job, this post-sync hook as part of my ArgoCD application along with NGINX application.

So I will go to my applications.

I have this NGINX ArgoCD application that syncs everything that is located into TestTrigger-Argo-demo/nginx, except for these two files.

It's excluding them. So I will now remove the post-sync hook file, and we'll update the application.

So our application is configured.

If we go back to the ArgoCD UI and refresh the page. And then we probably need to sync it again so it's out of sync.

Yep, and let's do the synchronization.

So we should see here the post-sync hook job.

Hopefully, we will see it shortly.

Bruno: Yeah, so for our viewers out there we are using NGINX as an example, right, for any application. So it could be any application that anybody has. They would use ArgoCD to deploy it, right? And then use post-sync hook would test it, right, for any change, right?

Yullia: Yes. So basically, we have here the job that was created a few seconds ago because we synchronized the application.

And it's already there because it executed successfully. It was deleted from the cluster because of the hook succeeded annotation. And if we go to the dashboard, we will see the cURL test that was executed a minute ago.

So basically that sums up how the post-sync hook works. Once we do trigger the synchronization, then the job is created. It triggers the test workflow that we defined there. And once it's successful it gets deleted from the cluster.

Conclusion

Bruno: It's really nice to talk about ArgoCD, how you can follow a GitOps approach, how you can test your applications while they are being deployed using GitOps, and you also for Argo Rollouts, the same thing.

If you do enjoy that, you know, feel free to give Testkube a try and try to integrate with your pipelines, your processes.

If you have any questions, we have a a big Slack channel full of members of our community, Testers, DevOps, people from all realms are there talking with each other and then helping each other to do better testing.

Also if you wanna send an email, you can just send an email to me at bruno@kubeshop.io, and I'll be really happy to talk with you. So, yeah. Stay tuned, and hope to see you guys in the next webinar that we do.

Yuliia: Yeah. Thank you. Bye!