Software releases

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

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).
• 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 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)

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.