-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
43 additions
and
0 deletions.
There are no files selected for viewing
43 changes: 43 additions & 0 deletions
43
...03-who-broke-the-build-using-kuttl-to-improve-e2e-testing-and-release-faster.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
--- | ||
title: "Who broke the build? — Using Kuttl to improve E2E testing and release faster" | ||
date: 2023-06-03T09:55:10Z | ||
github_username: chukka | ||
--- | ||
### Author's Name | ||
|
||
Ram Mohan Rao Chukka | ||
|
||
### Author's Bio | ||
|
||
Ram is a Senior Software Engineer at JFrog. Previously worked for startup companies like CallidusCloud (SAP Company), Konylabs. Loves Automation, Linux, openSource | ||
|
||
### Expected time | ||
|
||
Standard talk (~40 min) | ||
|
||
### Language | ||
|
||
- [ ] French | ||
- [X] English | ||
|
||
### Abstract | ||
|
||
No one wants to be responsible for breaking the build. But what can you do as a developer to avoid being the bad guy? How can project leads enable their teams to reduce the occurrence of broken builds? | ||
In talking within our own teams, we discovered that many developers weren’t running sufficient integration and End to End tests in their local environments because it’s too difficult to set up and administer test environments in an efficient way. | ||
That’s why we decided to rethink our entire local testing process in hopes of cutting down on the headaches and valuable time wasted. Enter Kuttl. Connecting Kuttl to CI builds has empowered our developers to easily configure a development environment locally that accurately matches the final test environment — without needing to become an expert CI admin themselves. | ||
These days, we hear, “Who broke the build?” far less often — and you can too! | ||
|
||
|
||
Session Outline: | ||
|
||
In this session, We’ll cover: | ||
● A quick history of our testing challenges and what led us to Kuttl | ||
● The benefits of our new testing approach — easy to configure and minimal investment | ||
● How we combine Kuttl and CI pipelines for more streamlined testing and fewer broken builds | ||
|
||
Session Key Takeaways: | ||
|
||
1. When and why we decided to rethink our e2e testing practices and our subsequent discovery of Kuttl. | ||
2. Why Kuttl has been the perfect tool for our developers to perform better local integration/e2e testing without the burden of becoming their own CI administrators. | ||
3. A detailed account of how we utilize Kuttl to set up development environments locally that match our final test | ||
|