Tracking where the time goes in your CI pipeline is an important step towards being able to make it go even faster. Up until somewhat recently, the only way of tracking how long tasks took in CI was either hoping people had wrapped all their commands in time ..., or by reading a timestamped build log and calculating the difference between numbers. Which isn’t great or fun, if we’re being honest....
Feature flags are a great tool for helping software development; they provide controlled feature rollouts, facilitate A/B testing, and help decouple deployment from release. So when it comes to building our software, why do we treat the CI pipeline without the same level of engineering as the production code? So, why not use feature flags in your CI pipeline? TLDR Reduce the risk of breaking a CI pipeline for all of a project’s developers by using the flagon CLI to query Feature Flags, opting developers into and out of new CI features and processes by targeting groups of developers or branch naming patterns....
Versioning is one of the many hard problems when it comes to writing software. There is no one correct way to do it, and all have various tradeoffs. After reading keep a changelog, I was inspired to implement this into a couple of CLI tools that I am working on at the moment: Flagon (feature flags on the CLI, for CI usage), and Cas (Content Addressable Storage for Make), but I also wanted to solve my versioning and release process....
Recently we were having a debate about release processes, and I wrote that deployments are not always equal to releases. also deploy != release —Andy, baiting discussion in Slack This turned out to be somewhat controversial until we discussed what I specifically meant by deploy and release. As with all things, agreeing on definitions or understanding what someone means when they use a specific term is essential, so I thought I would write down a short blog post on it....
On several occasions when building complex projects, I have been tempted to set up Bazel to help speed up the build process; after all, it has a lot to offer: only building what has changed, caching built artifacts, and sharing that cache between machines for even more speed. TLDR We can use Make and a couple of short shell scripts to implement file content-based caching and read/write that cache to remote storage, such as S3....
Well, for Applications & Services at least. For libraries, SemVer is the way to go, assuming you can agree on what a breaking change is defined as. But when it comes to Applications (or SaaS products, websites, etc.) SemVer starts to break down. The problem starts with the most obvious: What is a breaking change? How about a minor change? What’s in a change? For example, if we were to change the UI of a web application, which caused no backend changes, from the user perspective it is probably a breaking change, but not from the developers perspective....
So this is a bit of a rant…but hopefully with some solutions and workarounds too. So let’s kick things off with a nice statement: I hate broken builds. So everyone basically agrees on this point I think. The problem is that I mean all builds, including ones on shared feature branches. Currently, I work on a number of projects which uses small(ish) feature branches. The way this works is that the team agrees on a new feature to work on creates a branch, and then each developer works on tasks, committing on their own branches, and Pull-Requesting to the feature branch....
I have been a fan of CI (Continuous Integration) for a long time now, and ever since I started with CI I have been using CruiseControl.Net. CCNet is incredibly powerful; you can make to do practically anything, and writing plugins for it is a breeze. However, I do find that the config files get rather messy. I have tried many things and the current best solution seems to be to have one ‘master’ config file with a set of includes to other files....