How to Ensure Consistency in Multi-environment Structural Changes?

The version release of enterprise software typically requires a rigorous and standardized process, which includes multiple database environments, such as development, testing, pre-production, and production environments. The responsibilities of each environment are well understood and will not be elaborated here. The ultimate goal is to apply the code that has been developed and tested in the previous environments accurately to the production environment. To achieve this goal, it is essential to ensure that the order and content of changes at each stage are well documented and accurately executed in the next stage.

DBAs are the most critical role in version releases because if there are any issues with the database during the process, the first person to be contacted is the DBA.

Currently, most companies adopt the method of manually recording all changes submitted by developers by the DBA, and then manually executing them in the next environment according to the records. This approach requires the DBA to manually review the code and manually track the status of changes and approval processes, which is very prone to omissions or errors.

Some companies have chosen basic process platforms that can complete code submission and approval on the platform. However, due to the lack of database integration, approval can only be completed on the platform, and then changes are manually published. There are too many manual operations in this process, and errors and omissions are still inevitable.

Therefore, the problems we need to solve can be summarized as follows:

• How to ensure the completeness and order of changes?
• How to connect multiple environments to smoothly move changes forward?
• How to prevent change errors?
• How to simplify the release process?

Two Key Principles to Solve the Problem: Automation + Fixed Framework

Let's first talk about what the principles of automation and fixed framework are:

• Automation: Automation is the key to improving efficiency and reducing human errors. Through automation, the overall release process can be handed over to the platform in the form of tasks, thereby relieving the pressure on DBAs.
• Fixed Framework: A fixed framework is a structured approach that integrates the rules of task progression into the platform, allowing the platform to provide developers with clear steps and guidance, ensuring that the process follows the rules completely.

It's actually very simple to implement, just need a NineData platform and an account. Let's see how NineData follows these two principles to solve these problems:

• How to connect multiple environments to smoothly move changes forward: NineData provides two default environments, development > production, which is also a commonly used configuration. All changes will sequentially move from development to production. Of course, NineData supports user-defined environments and supports custom execution orders.

• How to ensure the completeness and order of changes: Based on the fixed framework of NineData, in the second and subsequent environments, only the code that has been successfully executed in the previous environments is allowed to be executed. At the same time, record the execution status of each change to ensure that all changes are executed in the predetermined order.

• How to prevent change errors: NineData provides SQL development specifications, with hundreds of built-in rules, and supports user-defined enterprise development specifications. The system will automatically intercept SQL statements that do not meet the specifications based on the specifications.

• How to simplify the release process: NineData is responsible for tracking and executing all process progress. DBAs only need to be responsible for manual review, which greatly reduces the manual operation links and reduces the possibility of human errors.

Things that are easy to learn and understand are usually more easily accepted by people. This is human nature and also the design concept of NineData. For the implementation of the above process, only a few simple steps are required on the NineData platform.

Step One: Enter Data Sources

Enter all the data sources of the enterprise into NineData, and pay attention to correctly select the corresponding environmental information of the data source when entering.

If there is no environment used in the enterprise here, it can also be created by customizing.

Step Two: Create Release Process and Bind Data Sources

On the process configuration page, you can add and delete nodes, and you can also add various restrictions to each node, such as whether to allow regression to the previous node, whether to allow skipping the current node, and whether to allow modifying SQL, etc.

Click on the target node to bind the data source for that node.

Of course, if there are only development and production environments in the enterprise's release process, you can also directly use the default process, just bind the data source, saving the other configuration process.

Step Three: Create Release Process

On the task creation page, select the baseline data source, which is the data source corresponding to the first node environment configured in the release process. Subsequent changes for all other environments will be based on the changes made in this data source. In this example, it is the development environment.

Enter the change statement that needs to be released in the Change SQL text box.

After clicking Create Structure Design and Release, the process can be started. Within each environment, developers (change collaborators) can submit multiple change tasks, and according to the approval process configuration, each task will go through the system's standard check and personnel approval.

After all changes in the current environment have been executed, you can click Enter the Next Node.

In each subsequent node, only the changes that have been successfully executed in the first node, i.e., the baseline data source, can be submitted. According to the administrator's configuration, the statements and execution order cannot be modified to ensure that the changes released in the production environment are consistent with the previous test results.

In the execution results, you can see that the changes have been successfully released to the production environment. Click Enter the Next Node again, and the process ends.

Summary

In the above configuration scenario, NineData will only allow new changes to be submitted in the first environment (baseline data source), and all subsequent environments will only accept changes that have been successfully executed in the first environment. This greatly ensures the safety of changes and can ensure that the changes released to production have been tested in multiple environments. Of course, system administrators can also set the process to allow changes to be submitted in any environment according to the business background, providing more flexibility for different businesses of the enterprise.

Finally, add a newcomer gift package. If the number of data sources in the enterprise does not exceed 10, you can use the above functions for free permanently. Not only that, all advanced features of the professional version can also be used for free permanently. Don't say much, just try it directly.