Continuous integration and continuous deployment have become the gold standard in the field of software delivery and deployment. This approach to software delivery transforms the way we develop, test, and release applications, bringing a host of benefits.
It accelerates the time-to-market, enabling organizations to respond to customer needs and market changes with unmatched agility. One of the aspects of a CI/CD pipeline that we are going to focus on in this post is Continuous Testing.
Continuous Testing ensures that every code change entering the system doesn’t break the existing functionality. While it is one of the most critical parts of a CI/CD pipeline, it’s often one of the most challenging ones when it comes to implementation.
In this webinar, we will:
Who should attend?
DevOps Engineers, Software Developers, QA Engineers, SREs - or anyone in-between. This event is perfect for those who wish to dive deeper or are curious about the world of testing applications in Kubernetes.
Hello hello everyone! Sorry for being a little late, how are you guys? Happy Thursday! I'm so excited to be back. Just last week we were at KubeCon, which is crazy to think about, so we had to push our Virtual Office Hours a week forward. We missed you, but we are back in full force, opening our virtual office doors.
My name is Ali, and I'm a Developer Advocate at Testkube. If you're new here, Testkube is a kubernetes-native testing framework that helps you orchestrate and execute the tests for your applications in Kubernetes.
Today we have a really cool topic. Just to summarize what this space is, this is our virtual corner of the internet where every two Thursdays of the month we chat about different techniques, practices, and ideas for testing your applications in Kubernetes. We discuss some challenges, how to tackle them, and of course, we update you on all things related to Testkube. Today we are going to talk about why test automation in your CI/CD pipelines shouldn't be hard.
Right now, it is just a common thing where if you're working with Kubernetes and you want to integrate a testing system into your pipeline, you know that you're in for a treat because it's not easy or straightforward. Regardless of the tool that you use, in this short Virtual Office Hours talk, we're going to show you why it doesn't have to be complicated and how you can do it easily using Testkube.
Let's go over the agenda real quick. The first thing we're going to cover is why integrating tests in CI/CD is so complex. Be it if you're a DevOps or Platform Engineer, a software developer, or a tester, you probably already know these challenges and can think of them straight away. Then we'll talk about how to set up Testkube with your CI/CD tools, and we're going to go over a few examples and demo them so that we can see them live.
To summarize real quick and jump ahead, you can set up Testkube with any CI/CD tool that you're currently using. It's not just limited to Jenkins and GitHub Actions; you can also use GitLab or GitOps tools like Argo CD, Flux, and whatnot. Anything that you're using, Testkube can work with it. However, in this case, just to keep things short and concise, we're going to talk about Jenkins and GitHub Actions. At the end of the talk, I'll leave some time for questions and just final closing comments.
We have a lot of documentation as well related to this. If, for example, you don't use Jenkins or you want specific examples with Argo CD or other tools, I'm going to leave the documentation link so that you can check that out. Our team of engineers, QA, and product leaders are great at crafting this content for you. We've pretty much rebuilt the documentation so that you have updated guides on how to get Testkube up and running with just any tool that you're currently using.
So let's start by covering why integrating tests in CI/CD is so complex. I think that we can all agree, or we've all come across this issue, that there are so many different tools and testing types. Integrating all of these testing tools and testing types within a CI/CD workflow becomes sort of a puzzle. Every tool has its own needs and its own setup, so configuring each of them might require you to set up test runners and services in your pipeline. At the end of the day, this ends up adding more complexity to the whole setup instead of making it straightforward, because it is time-consuming and it also affects the maintainability of your pipeline.
You can also agree that adding more stuff to your pipeline is just adding more steps. There are already a myriad number of steps involved with every part of your workflow, and as you increase this by adding more tools and steps, the complexity just increases as well. This can become really complicated sometimes to visualize, manage, and get an eagle-eye view of. All of these steps can make things very complicated for your engineers, your testers, and you as an infrastructure operator to understand what's happening at a glance. This leads to creating bottlenecks, increases turnaround times, and reduces the understanding of the pipeline's overall health, making it harder to pinpoint issues and detect the reason for a delay.
Another thing is definitely that you get limited observability and reporting. You don't get better reporting and alert mechanisms out of the box, meaning you would have to implement them yourself. It becomes really difficult to monitor how your tests perform in real time. In your CI/CD pipeline, since it's continuous, tests are ideally being executed continuously. Because of this, maintaining a record of performance becomes really difficult since you actually need to set up a way to retrieve historical data. Otherwise, you don't have it and you just lose everything, even though tests are being executed continuously. Moreover, your tests will be scattered all...