If you’re looking for guidance on how to integrate testing into your GitOps and Progressive Delivery pipelines - this is the Webinar for you.
Hosted by Bruno Lopes, Head of Product, and Yuliia Poplavska, DevOps Engineer at Testkube, this session dives into the synergies of automated testing and deployments for smoother, more reliable CI/CD pipelines helping you ship better products to your end users faster. What’s not to love?
Bruno and Yuliia will show how Testkube’s test orchestration capabilities align with ArgoCD and Argo Rollouts, enhancing deployment strategies through:
This webinar is perfect for DevOps engineers, QA engineers and Kubernetes practitioners eager to reinforce their CI/CD pipelines. Not an ArgoCD or Argo Rollouts user? Join us anyway, Testkube is compatible with all CI/CD tools. Come see Testkube and ArgoCD in action and gain practical tools for more reliable, efficient deployments!
Hi, everyone. Hope you are doing well, and thank you for joining our webinar. Today, we are going to talk about testing in GitOps environments, using ArgoCD and Argo Rollouts, and also leveraging Testkube so that you have a really good testing process.
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.
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.
So I can start with talking about the agenda...
So first, in this webinar we're going to introduce the concepts of GitOps and talk about progressive delivery.
We're going to talk about why testing matters in a GitOps world where people are doing everything more and more in the GitOps way.
Then, I'm gonna talk about Testkube and how it synergizes with ArgoCD and Argo rollouts.
And we're also going to do a few demos. We're going to show you how ArgoCD works when you have applications being deployed and you want to test them with changes and also different rollout strategies—mainly Canary and Blue Green deployments—and how you want to test them as you deliver them.
First, what is GitOps? So GitOps is a process of deploying and managing and monitoring your applications, that you are deploying your infrastructure in, using Git, a source of truth. And this is very helpful because, it works in the declarative way where you just define "how would you like your infrastructure to look like." And then you have to sort of many tools that work to make sure that, your infrastructure or your applications are deployed in the way as you declare them.
And it's very easy because, you know, you can version control that and you can make changes very easily. You can you can trace when you do something wrong. You can actually go to a commit and see, what was the issue.
So that's like one of the biggest trends right now in the cloud native world. It's making everything GitOps.
The other, concept is Progressive Delivery, which we're gping to, discuss later, in this webinar.
So, Progressive Delivery is, it's about, you know, reducing the risks when you are, deploying. So you deploy, in a way that you can catch issues early and deploy slowly.
The two main strategies for Progressive Deliveries are Canary releases, which is when you deploy, your application to a subset of, all your of your users. For example, you can say, I'm gonna deploy new version, but only 5% of my users will have access to it. This allows you to to understand if things are working well before then you launch it to the, you know, 100% of your user base.
And also Blue Green deployments is when you have, you know, deploy exactly the same application, test it, and then you switch the traffic to the new application the new version of application once you validate that it works.
So we're going to go more in-depth, about these different deployment strategies and how you'd like to test them.
So stick around to see, how you can do these sorts of deployment.
Next. So let's talk about Why Testing in GitOps Matters.
As you know, if you deploy and things are not tested very well, you're going to have downtime. You know, things are not going to work. Not only like the service can be totally unavailable, but also those things that are, will will produce a bad user experience, right, for our users. So, in a process you have a process that you can do a lot of changes and ship them fast to your customers, you want to test early.
So it's like kind of a shift-left mentality where you test, as early as you can and also test often. And this doesn't need to, let's say, impact your process in a bad way. Meaning, it doesn't need to add more time to your delivery, you know times, and it makes you like, you delay the release of applications. You can still test and and deliver things at the same pace.
And, one of the things that's not a disadvantage of having, like, a GitOps process is that—you have a lot of changes, right? You're going to declare everything, going to make a lot of commits and do a lot of small changes, right? And then it's going to be, difficult also to validate what changed and what needs to be tested in your infrastructure, in your applications once they are deployed. So you're like, you know, "We have to make sure that you have a really good process for this." Otherwise, you're gonna be introducing changes, and you're not sure if everything is working well.
Also, another another issue that you might have if you don't do proper testing is that you might detect an issue that is there, but you only detect, you know, after some time when probably your users complained to you and you didn't detect them. So it's better that, you detect them earlier.
So Benefits.
As I mentioned before, you can detect issues early and you gain time. The longer you wait to test stuff and understand if they are working or, things are working or not, then the harder for you is to debug it because then you don't know exactly what changed, right? So if you did one change every day, but you detect some some issue 10 days from now, we don't know if the change will introduce, like today or the next day. So it's it's it's easy for you if you detect any issues right away.
And, of course, doing rollouts, doing your deployments in a safer and and reliable way is what matters the most to you.
And, of course, you should have confidence.
You know, people don't like to deploy on a Friday because, there's a lot like a level of uncertainty about their deployments.
And if things go wrong nobody wants to spend their weekend fixing that.
But, actually, if you have a really good process where things are very well-tested and things are stable, you can even do sorts of things where you can deploy on Fridays.
So that's like that's one of the dreams.
So, a bit about Testkube. So how does Testkube fits into all that we discussed so far, right?
Testkube is a Testing Control Plane that will allow you to orchestrate all of these tests during your deployments.
So if you use Kubernetes clusters, it allows you to have test observability into those clusters and actually orchestrate the execution of those tests, and also synchronize with your deployments.
It supports all of the different frameworks, different testing tools, different types of tests from load test, API test, anything.
And as I said before, it integrates very well with your tools and CI/CDs.
So what are the the benefits?
Like all the GitHub tools, you can also define, all the tests you want to run, as codes.
So Testkube has something called Test Workflows. It allows us to define how you'd like your test to run. Yeah, I was talking about the the Test Workflows that, our users can deploy them as YAML.
It integrates with the Argo Rollouts, so it allows you to test while you are doing rollouts. Both for, Canary, releases or Blue Green deployments, you can connect to Testkube, and Testkube is kind of the source of truth that tells Argo Rollouts if you can proceed with your deployments or not.
Also with the ArgoCD, you can do something called Post-Sync Hooks that allows you to test the changes. And, also, we'll give you a dashboard that gives a really nice, visible way of checking all of your tests.
I guess that's it for introductions and explaining what we want to do on this webinar, what we want to show to you, and what is the value. So, I guess now it's back to you.
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 a 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 Wokflows, 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.
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.
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.
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.
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.
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.
Let's move to the Kubernetes Event Trigger and Argo Post-Sync Hook. So I will 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?
Yes.
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 task 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--
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.
Yeah. Exactly. Okay. So you're seeing my, repository. Is that correct? Yeah?
Yeah.
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.
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.
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.
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 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.
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?
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.
Cool. So: Argo Rollouts. This is the another tool from Argo that leverages advanced Kubernetes deployment strategies such as Canary and Blue Green.
There are other benefits that you may get from Argo Rollouts like, service mesh integrations, metrics provider integrations, and etcetera. But today we will focus on the deployment strategies and how Testkube can be integrated into this workflow to ensure tested and verified deployments.
In our first demo on our Argo Rollouts, we will release another NGINX application that has an endpoint to the outside world, in two versions using a canary strategy of the deployment. So, Canary: this is the progressive rollout of an application that, splits traffic between an already deployed, version and, a new version of the application. So, at the beginning, you may redirect, let's say, 10 or 30% of the traffic to your new version, and then gradually, decrease it until you reach the one 100%, and the new version will be deployed, will be served, fully to your users.
And I think I will also mention the Blue Green, so that we can cover these two in theory, and then I will just do the demo of both so that we don't don't do the slide-switching.
So another part of the demo will be dedicated to blue green deployment.
So this is the deployment strategy where basically it transfers user traffic from the previous version of an application that is the Blue environment, to a new release, the Green environment.
The new version is firstly tested and approved, and then the traffic is transferred from blue to green. If any issues arise then traffic may be reverted back to the old version environment.
And basically to detect these possible issues, we will use Testkube to run a test workflow that will verify the stability of a new deployed application
version.
Very similar to the previous demo, we will need the same--we'll use the same Kubernetes cluster, the same dashboard, with the same workflows.
The differences are that we will have the Argo Rollouts installed into our cluster instead of ArgoCD.
And we will use the analysis template and Rollout manifests to, basically, to rollout to and progress our deployment of new application versions.
Let's open the Argo Rollout folder, and we will start, let's say, with canary.
To deploy Canary, we will need these two files, basically very very simple I would say, in their configuration. So Analysis Template: it reminds the post-sync hook job in its configuration.
So basically, Analysis Template defines: it analyzes if the deployment is progressing as desired. So it runs, in our case, a test workflow to check if the new application version is reacting to our test as we desired. Basically, if it passes our test then it can progress and the number of traffic can be decreased--that can be increased to the new version. That's correct. So let's let's see...
If I can add to it, Yuliia. So, what our users would do is maybe could be a load test, maybe an API test, right, that they would have. They would get maybe from any framework--could be from Postman. There're people who do using that using cURL, there's Playwright as well, right? So it can be any type of test or testing tool, and they would use that test. They will define it in Testkube, right? They import it as a test workflow, and then trigger it.
Then the trigger here is when Argo Rollouts will define when to trigger that test, and Testkube is kind of the source of truth that tells if things are passing or failing. So Argo Rollouts understands, right, if it should if it should continue or not.
Mhmm. Yeah. Exactly. Thank you for that. Yeah. You put that correctly.
So, let's go through the analysis template. So, basically, it does the same: it launches the Test Script CLI container with the same environmental variables. It sets the context and runs this k6 test workflow. As Bruno mentioned, it can be any workflow. It can be a set of test workflows, it can be a complex workflow, like anything that your application requires. We also define here the success condition and the result exit. This basically implies that the new versions analysis, deployment, and traffic progression will only occur when the test workflow is completed successfully.
So, if of course, it fails then the progression will be aborted completely.
This is basically all for Analysis Template. Let's take a look at Rollouts. Rollouts: this is like a substitution of a deployment. It's very similar to the deployment in its manifest except it has different API version, kind, and, the strategy that's specified in this manifest. So we can see that this is the canary strategy. It uses the analysis template, the one that we've seen previously.
Then, firstly, it start with the Weight. Set Weight to 30%. So Weight is basically the percentage of traffic that will be sent to the canary pod. Then the deployment pauses for two minutes and the analysis run is started.
Once it's successful then the traffic will be fully directed to the new application version.
So here we also have the the labels and the container.
This is my application image, basically, the image proposed in the container port.
As the rollout is basically our deployment, we have a service, a very basic one, and the ingress that will expose our application to the outside world.
So let's deploy it!
Let's go!
I like your terminal. Like, the team is doing this.
Yeah. I installed some extension some time ago, and I forgot what it's called. And, people sometimes ask me how is it called? And I said, I just forgot because it was some time ago.
So I'm prepared okay, cheat sheet for me. So firstly, I will, deploy the analysis template.
And then I will deploy the rollout, the first version of the application.
So, to mention also, we will be using the Argo Rollouts dashboard that can be exposed, can be accessed on our local host in our browser by just running this command. I will open it in a different tab.
Yeah, we can see here that for now we deployed the first revision of our application.
It's stable.
It has this image. It also shows us the step from the rollout template. And yeah basically, that's it.
Let's try also to access the application.
Yeah. So now we have the the first version of the application deployed by the canary strategy.
And now let's update our image to the second version application, and see how the tests the how test workflow is being executed and whether it's successful or not, and how the traffic progression will happen. So for this I will use the Argo Rollouts CLI that I have preinstalled before the demo.
And I will run just one command that will update the image of my application.
So this is the command. It uses the Argo Rollout CLI.
Then it sets the image of this rollout, and basically it sets the the image of this container, that belongs to this rollout, to this value.
Let's run it.
Yeah. Now it's been updated, and we can also watch the progression from the CLI as well as from the UI. So we can see that the new bot is already running. Oh, the job analysis is successfully. It's verified.
But now it's paused because we set it to pause for two minutes as we can see here. So we can go back to our UI and see.
Refresh the page and see that we should have the second revision. Yeah. That's right. We have the second revision, and we have the analysis run, which is successful.
It ran the test test workflow. If we go back, to the dashboard we should see this execution there.
Yeah. That run a minute ago. We have this k6 workflow, and it was successful which means that after two minutes, our application will be running the version 2.0.
Yeah. You see that sometimes we hit the version two, because 30% of our traffic is directed to that canary pod, to that second version.
So sometimes we will hit 1.0 most of the times, and sometimes we will hit 2.0.
It's pretty cool.
Yeah. And, once our time is up, let's check how much is left. So, yeah, we still need to wait, like, thirty seconds.
And then we will see that, the old pod will get turned down. It will be destroyed, and only the new revision will be serving the traffic.
Okay. Let's watch the terminal...
So it will be 120 plus, like, three seconds delay, and then the old pod will start terminating.
Yeah. You see, it was there. So, it was the the old one was terminating, and the new revision is now progressing and will be running the stable version of our application.
So if we go back to the UI, we will see that revision 2.0 is now the stable and the current version of our application.
And if we go back to the endpoint, we will be only serving the version 2.0. So yeah.
Okay. So then I will get back to my terminal. I will stop the live progression, and then let's switch to the blue green. The blue green kind of deployments very similar to the canary in terms of manifests. It has the same template, almost, and identical except for one difference.
We defined here a different test workflow. This test workflow will fail on purpose because I want to demonstrate how Testkube can prevent further deployment when there is a bug or any kind of issue in the application when it's not passing the test that it's supposed to pass.
And here we have the rollout.
Almost the same manifest, except for it has the blue green strategy specified instead of canary.
Here we specify the active service, the also the NGINX service that we have deployed.
We can also have here the preview service, to access, to further troubleshoot, to check the application, but we won't be using it here in this demo.
We have autoPromotionEnabled:false because we want to promote it manually, let's say, here.
PrePromotionAnalysis. This is the analysis that we've seen before, the one that will be running our test workflow.
We have RevisionHistoryLimit set to 2, and the same set of labels and also the containers configuration.
We have this image here that we will be updating as well as we did for the canary.
We have the service and the ingress that we'll be exposing our application.
Let's let's deploy the blue green!
So firstly, let's deploy the template.
And the rollout.
So we have the rollout created for the service and ingress. I have to create it before because it takes time for the ingress to be initialized, for the certificates to be created, and so on and so forth. So, to have it quickly up and running, we just create the rollout.
And if we go back to their Argo Rollout UI, we will see here the blue green type of strategy. It has the version 1.0 version of our image of our application.
It's stable.
It's active. It's running. It's working.
Let's then go to the ingress, to the endpoint.
So we have our application, at 1.0 version, and let's update the image the same way as we did for the canary. We will just use the Argo Reload CLI.
Okay. Image is updated, and let's watch live how the progression will go.
Okay. So it has the new running pod here, and it's performing the analysis run.
Let's go to the UI and check also.
Yeah, so you can see it's deploying. It's running the analysis, and we can open the test workflow that's been executed at the moment.
Okay. So it failed, and, it it was supposed, it's supposed to fail. And now we will go to the terminal and we should see here the-- once it's analysis will be finished, we should see that the deployment will be rolled back to the previous version.
Pretty cool that we can see all of this as it's happening. Like, it's running the test. You can really see everything that's going on on the cluster.
Yeah. How it's running.
Yeah. So it failed, and the rollout is in degraded status. So it's basically reverting everything to the previous version of the application.
And the same we can see in the ArgoCD—Argo ROLLOUTS highlights.
We have the same we can see in the UI. So the analysis failed as you may see here. So assessment is failed and we're still running the two point—1.0 version of application which is active and stable. So no changes here.
And I think we can back go back here and we can see that the new revision is scaled down. It's not it has not progressed further because the analysis failed and basically all rollout has been reverted back to the previous version.
Yeah. And I guess that's it for the demo for today.
It's a it's a bit longer than we, expected. Right, Bruno?
Yes. It's really cool. I think we covered all the ground and explained all the nuances of deploying, using ArgoCD, using Argo Rollouts, and what things you can do.
Yeah. It's really nice.
Just want to reiterate that you can find all the examples at our repository, testkube-examples. There is the link in the presentation.
And basically, you can try to do these experiments on your own.
Awesome. Thank you, Yuliia. So I guess I'll go back to the slides. So thank you everybody for coming. We're going to put the links to the examples, to slides for everything in the description of the video.
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.
Yeah. Thank you. Bye!