The Last Spike Online / 15 July 2026
The game barely existed, but it already had reproducible development and release workflows
Deployment was not postponed until the end of The Last Spike project. Development and release Docker workflows were introduced early so every later feature would travel through the same path to production.
Situation
On a small project, it is easy to say that the game should be finished first and containerized or deployed later. That looks faster in the short term, but every new feature then builds on a runtime known only to the local machine. By release time, application and infrastructure problems arrive together. I wanted to remove that risk at the beginning of the project.
Approach
I created separate Docker workflows for development and release with a shared, versioned runtime foundation. The local environment optimized for fast iteration, while the release image used a minimal and predictable serving layer. Rather than forcing one Compose file onto every situation, I separated the common base from environment-specific responsibilities.
Outcome
By the time multiplayer and a production domain arrived, build and deployment were no longer new problems. CI could package the same code that had been tested locally, and production changes no longer depended on undocumented manual server state. Release engineering became part of development instead of a final-weekend task.