Configuration deployments can be used to maintain the state of Apps and Configurations across multiple Subscriptions. If you have multiple accounts, you can also use configuration deployments to deploy changes across all of them at once.
The number of needed Subscriptions (deployment environments) depends on the specific business needs.
Working with Only One Subscription
Only one Subscription is enough if the managed processes and data are not critical or a short downtime due to configuration changes does not impact operations. With an all-in-one development and production environment, changes are reflected in the production environment at any time. The single development and live Subscription is used by developers, QA, and key users, as well as for users who need to test the application simultaneously.
Only one Subscription significantly increases the risk of data loss due to configuration problems. Only stay with one Subscription if the induced risk is managed and acceptable for operations.
Working with Two or More Subscriptions
Two or more Subscriptions are needed if the development (build) Subscription must be separated from the productive Subscription, and downtimes due to configuration changes must be kept to a minimum. You may have a development Subscription that is used to build and test your processes, while a separate productive Subscription is used to deploy your configuration to production.
If you have multiple Subscriptions and they are used for different purposes, an additional test Subscription for each productive Subscription helps to clearly separate the different development environments and to avoid mixing processes and configuration.
Working with Three or more Subscriptions
Three or more environments are needed if regulatory requirements or dedicated test environments dictate the separation between the development, test, and productive, live environments.
- A test environment allows you to run isolated tests against your application. This can be used to ensure that all changes made have not caused problems in the application or processes.
- A production environment then only runs validated and tested processes and configuration of tested deployment packages
Novunex Subscription Governance
Multi-Account Deployments
Special business requirements (multi-national teams or different locations) may induce the need for seperate accounts and Subscriptions (in different accounts). Multiple options and strategies are possible to manage development, testing and deployment of configurations.
The main advantage of the centralized vs. decentralized Novunex Platform development is that it allows for a more standardized process, as well as a single point of access for all developers. In other words, it’s easier to manage and enforce a system where everyone is working off of the same version of the configuration.
On the other hand, there are some disadvantages to this approach. One major downside is that it’s less flexible. Because everyone has to wait until the central build has been completed before they can start working on their own individual configuration (to test or adapt), you can’t adjust your release schedule if something unexpected happens. Additionally, this approach can result in an additional effort being required from each developer, test engineer, or key user to align their efforts with those of their peers—making it harder for them to move quickly and independently.
Overview of some deployment strategies
Individual accounts and subscriptions
Use cases
- Individual accounts or Subscriptions
- Individual requirements or needs
- Different teams or processes
Pros and Cons
Pros:
- Flexibility: the ability to adapt quickly to change and new requirements.
- Low alignment effort: the ability to focus on what’s important and avoid unnecessary effort.
- Decentral release cycles: the ability to release at the individual’s pace and not wait for a centralized release.
Cons:
- Non-standardized processes: individuals are responsible for creating their processes, which may not be consistent with other teams or companies.
- Individual build and test effort: individuals must develop their own build process and test strategy rather than using an existing one provided by a third party.
- No synergy, individual development: there is no cooperation between teams, so everyone works independently, which can result in duplicated work or missed collaboration opportunities.
Shared development
Use cases
- Connected accounts or Subscriptions
- Aligned requirements or needs
- Different teams but the same processes
Pros and Cons
- Less-Flexibility, alignment effort needed for processes
- Decentral release cycles: still the ability to release at the individual’s own pace and not wait for a centralized release.
- Standardized processes: Consistent across teams or companies
- Central build, individual test effort
- Synergy on build, individual test
Standardized processes can help increase team consistency but make it harder for teams to adapt quickly to unique situations. Central build and test efforts can help mitigate this problem by providing consistent results across all builds, but they give less flexibility in terms of what tests are run or when they’re run. The synergy between teams can help mitigate the downsides of each strategy while still allowing both options to be used effectively if needed.
Centralized development / mix test
Use cases
- Connected accounts or Subscriptions
- Aligned requirements or needs
- Shared teams, same processes
Pros and Cons
- No flexibility, alignment effort
- Mixed release cycles
- Standardized processes
- Central Build, individual test effort
Testing configurations across an entire organization and departments is a great benefit. This allows for a more streamlined process because fewer people are involved. In a “mix test” scenario, some processes or configurations are tested centrally, and specific customized processes for local requirements remain a test responsibility for each team.
It also allows for more transparency and collaboration between teams, leading to better communication and higher quality work.
Centralized development and test
Use cases
- Connected accounts or Subscriptions
- Aligned requirements or needs
- Centralized teams, same processes
Pros and Cons
- No flexibility, alignment effort
- Central release cycles
- Standardized processes
- Central build and test effort, synergy
Centralized development and test strategies are the ultimate in structured and controlled environments, but this can come at a cost to flexibility. When you have a centralized organization, central configuration management approval is needed for every change. Decentralized development teams can be more flexible but require more effort to keep everyone aligned.
If you’re working with a centralized organization that has standardized processes, then there will be one set of release cycles that everyone follows. Every department or team will have defined deadlines and milestones throughout the year or quarter, depending on the development stage.