Inside Cloudtheapp – Configuration Management Deployment Strategies

All the world’s a stage and most of us are desperately unrehearsed.
― Seán O’Casey

Configuration Management (CM) is a process intended to manage system changes from inception to delivery. It ensures best practices, regulations, and standards are consistently followed, while minimizing errors, improving efficiency and maintaining system integrity. CM is defined by various standards including (ISO 10007:2017) for QMS.

Regardless of your software release process or the regulations your business must comply with, using separate stages (environments) to organize your system at each step of the process is a critical part of CM.

We will start with an example of a typical multi-stage setup, then explain why stages are important, list the most common issues, and finally how we address them. 


Typical 3-stage setup:

  1. DEV: This is where it all begins. Configuring a module, process, or changes to existing ones are performed here.
  2. QA:  Once the change is considered stable this stage is used to run all types of testing. Results are reported and issues may require further fixes or a redesign at the DEV stage. These would in turn be rolled out into QA in the next iteration.
  3. Prod: Once a change passes testing, it is deployed to this final stage and available to end-users.


Advantages of Multi-Stage Setup

  1. Uptime: It allows your configuration team to work on and test new changes without affecting the live system.
  2. Efficiency:  Configuration and testing teams can work in parallel on the different environments and changes.
  3. Training: Users can be trained on and can try out the change before they are released. This can be done in a separate (Training) stage.
  4. Creativity: Your configuration team can experiment with different approaches or new configuration options without risking having these experiments end up in a stage that is part of the deployment path to production. This is best done in a separate (Sandbox) stage.
  5. Security: It is not a good idea to give your configuration or testing teams access to live data as this may compromise privacy or confidential data. Having multiple stages means production data can stay in production and each stage can have data and permissions appropriate for the tasks performed there and the authorized users on that stage. 
  6. Validation: Businesses required to follow strict validation regulations can maintain a separate validation stage that has identical configuration to production and to which the configuration is transferred only once all tests pass on the QA environment, just like production. This ensures that the validation tests performed at that stage are applicable to production.
  7. Recovery: A separate stage can be used to backup production configuration prior to updates.


Common Problems

  1. Costs and provisioning: Often setting up a new stage (or environment) is a long and complicated process that requires analysis, managementnand IT approvals, purchasing or provisioning new servers, Networking and security setup, and so on.  
  2. Manual Reconfiguration:  Your team may have spent months creating a new module on DEV, only to have to redo the process on QA and Production. This would waste time and effort and increase the chance of human error.
  3. Unreliable Automated Configuration Transfer Processes:  Some platforms come with a built-in automated feature to transfer configuration across stages. However such processes are often slow, hard to use,  and notoriously unreliable. Unexpected issues and differences between stages could cause the transfer of changes to fail or worse bring down the production system all together.
  4. Copying Configuration across Stages using standard database Backup & Restore: This is used by some as a quick alternative to manually redoing DEV changes on a testing stage. While it may produce a good copy of the original, this invalidates the integrity of the testing since such a process cannot be used on production as it would replace live data.


There is a Better Way

Cloudtheapp is a SaaS Cloud platform, that means you don’t have to worry about provisioning servers for new stages. You can also instantly create unlimited stages to organize your apps with the click of a button.

Typical DEV, QA, PROD stage setup
Instantly create unlimited stages as needed

You never have to redo changes manually since our configuration transfer feature does it automatically and in under 5 seconds.

Transfer module configuration without data to another stage in seconds with 1 click

It will make the configuration on the target stage you select identical to the source without copying the data. As a no-code platform, the consistency in configuration means the process is reliable every time.

Our Software platform (including the configuration transfer process) is already validated with full documentation which can be leveraged. This will save your validation team time as they only have to validate the configuration your team performed as opposed to the platform itself. 


Conclusion

Using multiple stages combined with a simple, automated configuration transfer tool, and the power of the cloud and no-code ensures your changes are reliably transferred and thoroughly tested while streamlining your release process.

Supercharge the configuration management of your QMS and/or digitization platform and signup to Cloudtheapp today.

Share this post

Sign Up for Cloudtheapp

New to Cloudtheapp?

Access to try Cloudtheapp can be granted after you request a demo to learn how it can transform your operations.

Existing Customer User?

You can proceed with signing up.

New to Cloudtheapp?

Access to try Cloudtheapp can be granted after you request a demo to learn how it can transform your operations.

Existing Customer User?

You can proceed with signing up.

Please complete the form to access the Case Study

Please complete the form to access the Case Study

Please complete the form to access the Case Study

Please complete the form to access the Case Study

Please complete the form to access the Case Study