Software releases
Tags: webdev, programming, productivity, architecture
Published: 2023-02-02 10:17:30

## Intro
It depends .... 😜

This is the common term in software industry. And for the most part its true. Unless you know about the goals of the software you cannot determine a release process. Generally there is a standard framework(that I observed working in 10+ projects):

Note: the software here means both frontend and backend

- Split the software into small **deliverable modules**. Ex: to build a motor cycle start by building a skateboard, then a cycle then a motor cycle. This way you can use and test each module.
- Build minimum **3 environments** where the software can be deployed. ITs more like having same software running in 3 different servers and 3 domains
   - dev.mysoftware.com - Development environment
   - stage.mysoftware.com - Staging / beta environment
   - mysoftware.com - Production / main environment
   - test.mysoftware.com - Temporary testing environment

Each environment will have it's own code running in backend and frontend servers. Each environment code will be different and will be a different branch in the GitHub repository.

#### Development environment
This is where developers can deploy all latest working code and release to testing.

#### Staging environment
This is essentially a well tested copy of software with new features or modules waiting to be tested and approved by the stakeholders(Who own the software).

#### Production environment
This is where fully approved software is deployed and used by the end users.

### Testing environment
If only obsoletely necessary, we can have this environment to test any new things we try. Like DevOps terraform or AWS etc.. integrations.

## Release cycles
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4p2wh7ye67g5o06p2gp4.png)
### General code release process
- When working on a module / feature create a feature branch from development branch and work in it.
- After completing feature development. Update the feature branch code in development branch. Normally we use PR ([Pull requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)).
- Deploy to development environment.
- Initiate testing.
- Do bug fixes if there are any. Here as well create a bug fix branch and move the code to development using PRs.
- Post testing passed, move development code to staging branch.
- Deploy in staging environment.
- Perform a sanity to ensure all changes are working fine.
- If there are any bugs identified in sanity then fix them by creating a new hotfix branch from staging. Make sure to move these hotfix changes to development branch as well. 
- Post completing sanity, move all changes in staging to production branch.
- Deploy production branch. [Do not do testing in production]


### Release with feature flags
Post releasing a feature or change to production. Suppose, this new feature needs to be **rolled back or put on hold** because of any issue, for example server / website performance is slow. Then our only way is:
1. Create a hotfix in staging to remove this feature
2. Test this change
3. Do a bug fix if this change causes any issues
4. Re-test if any bug fixes
5. Move code to production.
6. Repeat the same, from step 1 to enable this feature later on.

This is very **expensive** and includes **multiple developing and testing cycles**. Can we avoid it? Oh yes, **feature flags**. They are similar to environment variables. Each environment will have different values but the name will remain the same.

The concept is to develop features with **feature flag conditions** in place, in such a way that,
- If the flag value is **true** then feature should be **enabled** or shown in the software.
- If the flag value is **false** then feature should be **disabled** or should not be shown in the software.

Hence, here if we need to rollback / switch off a feature, its very simple. We just need to set this flag as false and re-deploy or use a cloud third party like [LaunchDarkly](https://launchdarkly.com/) and change the value to false.

Once a feature is in production and working fine. We must **remove** this feature flag conditions form code.

### Release with scientific experiment
This is special case for microservices covered in this article [How to test new microservice APIs - (Monolith to Microservice)](https://dev.to/vishesh/how-to-test-new-microservice-apis-monolith-to-microservice-2oi8)


## Few additional tips:
1. Think ahead of time and maintain a sheet with release check lists. It will help in future.
2. Make sure that infra setup is working fine before deploying.
3. Double check with environment variables.