In an ideal world CI pipelines would never fail and deployments would be easy to navigate. The reality is that the journey from commit to production can fail in subtle ways that can be hard to understand. And this problem is multiplied by the number of pipelines in your system.

Building full-stack applications can be challenging, especially when developing the backend and frontend at the same time. In this scenario, frontend teams may have to wait for the backend team to finish building an API before they implement. This is where Mirage.js comes in. In this tutorial, you will explore how to use Mirage.js in frontend applications and mock backend requests for services that have not yet been developed.

Every team has guardrails, whether you recognize them or not. They’re a form of automation that can have significant impact on your software development process and the people doing the work. They’re another way to give toil the boot and keep developers in the flow. We’ve made the case for engineering automation in a previous article; here’s how guardrails as automations ensure that agreed upon boundaries and ways of working are codified into team processes.

A pull request (PR) is (quite literally) a request to pull a change into a project’s code or documentation. It is a popular change management process supported by many VCS providers including GitHub, GitLab, Bitbucket, Codeberg, and others. Typically these come with features to track open pull requests, tools to assist in reviewing the changes, the ability to approve—or reject—PRs, and finally to merge approved PRs.