top of page

Three Stages of App Deployment: Build, Release, and Run



When we talk about getting our software from the drawing board to being live and serving users, it's helpful to think of it as a three-part process: Building, Releasing, and Running. Let's break down these stages with easy-to-understand examples to clarify the journey from code to customer.


Build Stage: Crafting the Executable

The Build stage is where your code takes its first steps towards becoming an operational application. Here, the code from your repository undergoes a transformation process. This includes fetching any necessary dependencies, compiling code into binaries, and preparing all assets required for the application. The build is created from a specific version of the code, frozen at the time of deployment, ensuring consistency.


For example, Imagine you're working on a web application using Node.js. During the build stage, you would run commands like npm install to fetch dependencies and perhaps use a tool like Webpack to bundle your JavaScript files and assets into a deployable package.


Release Stage: Merging Code and Configuration

Next comes the Release stage. This stage marries the build produced in the previous step with the current configuration settings specific to the environment it will run in (such as production, staging, etc.). The outcome is a release, a version of the app that's ready to be executed in its environment.


Consider you have a build of your Node.js application ready. The release stage would involve taking this build and applying environment-specific configurations, such as database URLs or API keys, which are not stored within the codebase for security and flexibility reasons.


Run Stage: Execution in the Environment

Finally, the Run stage is where the magic happens: your app comes to life in its execution environment. The processes defined in your release are started, and your application begins to serve its users.


In this stage, your previously prepared Node.js app is now running on a server or a platform like Heroku or AWS. It's actively responding to user requests, accessing databases, and performing its designated functions without further changes to its code or configuration.



Importance of Strict Stage Separation

It's crucial to maintain a strict separation between these stages. Once an app reaches the Run stage, no changes can be made to it directly. Any modifications require going back to the Build stage, creating a new release, and then moving to the Run stage again. This separation ensures stability and predictability in your app's behavior.

"Think of your app's journey from code to customer like a relay race: the Build stage crafts the baton, the Release stage passes it with precision, and the Run stage sprints to the finish line. Keep each part clear and separate to avoid dropping the baton and ensure a smooth race every time."

An example scenario is like, Imagine you need to update a feature in your app. You can't directly tweak the live version. Instead, you return to your codebase (Build), adjust the feature, create a new executable (Release), and then deploy this updated version to replace the old one in the Run stage.


Immutability of Releases

Every release is immutable and uniquely identified, typically by a timestamp or an incrementing number. This immutability means once a release is made, it cannot be altered. For updates or fixes, a new release must be created. This approach simplifies rollback and tracking, as each release stands as a distinct, unchangeable milestone in the app's development history.


Release Management and Operational Simplicity

Deployment tools often offer features to manage these releases, allowing teams to roll back to a previous release quickly if needed. This is akin to keeping a history log where you can undo changes by simply switching back to an earlier version.


In practice, the Run stage aims to be as simple and reliable as possible to minimize failures, especially during critical times when developer intervention isn't immediate. The Build stage, conversely, can handle more complexity since it's under active developer oversight.


In Conclusion



Understanding and implementing the Build, Release, Run methodology not only streamlines the deployment process but also enhances the reliability and manageability of applications. By adhering to this structured approach, developers can ensure that their apps are built, released, and run in a predictable, efficient manner.


Comments


The Occasionally Amazing Newsletter!

Thanks for submitting!

© 2024 visakhunni.com

bottom of page