CI/CD has become a standard tool in every modern software developers day to day experience. We demand a lot from our CI/CD systems! and our software is all the better for it. But I think a lot of us have a slightly under-principled way of talking and thinking about it. Specifically I want to talk about how we tend to lump two very different types of tasks under the banner of "tests" or sometimes we don't even talk about one of these types of tasks but we still have them sitting in our pipelines and workflows and what have you.
you think having 3 repositories and NixOS involved in running a static website is ridiculous? Well, no, you are ridiculous!
A step-by-step guide on how to add code coverage to your .NET project in Azure DevOps.
Configuring an Angular standalone application to be flexible enough to be released in different environments.
Playwright v1.37 introduces a new `merge-reports` command. In this blog post we'll see how leverage this command to create a single test report from different sharded test reports. The result is one page containing all of your test results.
At some point in time you'll want to run a subset of your tests. Organizing your tests with Playwright test tags helps you to do this in a clean way. Using tags allows you to target specific tests in specific scenarios, and can help to scale your pipeline(s).
Utilizing a matrix within your GitHub workflow to create a "test shard matrix" is a major improvement to your CI. This practice can cut the time in half (or better) to run your Playwright test suite.
Make your CI/CD pipeline smarter and only build (and release) what's modified to optimize a run
In our quest to build a twelve-factor app where we build once and deploy to multiple environment we encountered some problems, but we managed to solve them. Read here how we did it.