Observability
In my recent posts on managing a commit-oriented infrastructure, I explained the benefits of deploying services of one specific version. This version would be the hashed Git commit reference, or commit SHA. When running this kind of setup, you might encounter the question of which version is running at the
CI/CD
We spend a huge time thinking about building our products, but less about the pipeline that delivers features from engineering to production. Ideally, we want to test the latest changes before they're released to all our users, even if we carefully hide them behind feature toggles. We also
GitHub
GitHub has become the platform where millions of developers get their work done, and as such, one of the biggest targets for building integrations. Whether we're adding Slack notifications for pull requests, connecting our productivity tools to our code, automating deployment and release procedures with CI/CD, or
Engineering Management
Imagine the following: You've just completed a polished new feature, upgraded some dependencies, found some code paths that needed refactoring and worked on several other things you're about to release. Unfortunately, your existing commit messages look something like the following: $ git log Commit 453a620131169ed327d8d35ba4952ba5 added cool