You can get to production faster by separating CI and build/deployment process. But there’s risk in it. Here are two approaches to help with the decision.
I’ve previously explored whether or not you should run continuous integration (CI) during your production build process. There are several factors to consider.
If you decide to separate the two, there’s scenario that immediately becomes a challenge: How do you maintain parity between CI and the production build?
Before we answer that, we should consider why _having parity matters. The main reason is that there may be _something that occurs within the CI process that suggests you shouldn’t publish the production build.
Given that, I see two approaches for configuring these two services:
Let’s briefly explore both ideas.
This method suggests that both CI and production builds are happening in parallel. But if something goes wrong in CI, you would roll back your production build.
The main advantage of this approach is that you can get to production faster. The CI process is offloaded to another service.
The downside is that you could send bad code to production. But, there are ways to mitigate that risk. For example, you could include your most mission-critical tests as part of the production build, and use CI for tests that you might still roll back, but that wouldn’t cause a major outage for your users.
Alternatively, you could still run in parallel. But instead of deploying the production build, you wait until CI completes, and then trigger the deployment.
The main advantage of this is mitigating the risk in the scenario above. Here, regardless of the severity of the bug, if CI catches it, the build never makes it to production.
This also has the advantage of not needing to worry about which tests are mission-critical or not.
The biggest challenge here is mainly that it’s complex. For example, you could do it with Netlify, but you’d likely have to build some automated service using their CLI. Thus, you lose some of the magic of Netlify and take on that work yourself.
There’s also a risk here in that if your CI process runs longer than your production builds, it takes longer to get into production.
I often say choose the best tool for the job. There is no universal best tool for any of this. You know your project better than I do. Weigh these two options, choose one that feels right and try it. If it doesn’t work, try the other. And if neither are working quite right, perhaps it’d be better to run CI and build/deployment on the same server.
Four considerations when deciding to run continuous integrations with production builds or as a separate workflow.
Commit file changes created during a GitHub automated workflow run.
Static site generators are all the buzz today. But what are they really? And how do they fit into the Jamstack?