Module Generator: Test and release configuration change

The ModuleGenerator provides many tools and aids for designing, testing and operating an module. As simple as the configuration in the module generator is, the processes mapped with it are often very complex. Complex processes inevitably result in complex configurations. Therefore, the module generator checks the configurations for errors and logic gaps.

The initial release of an module is the simpler case. However, subsequent changes to an module running with production data during ongoing operation with automatic data migrations is also greatly simplified and supported by the module generator. These two scenarios are briefly explained below.

After creating the new configuration via the individual module list and setting up this configuration, a typical release proceeds as follows:

1. The configuration is checked for errors and problems. This check can already be seen during the configuration at the icon in the upper right corner - see Configuration errors and problems (article follows). A problem can be ignored if necessary, but a configuration error must be fixed before the next steps can be taken.
2. Testing the module. To do this, select Test configuration in the main navigation. A test version of the module is created in a new browser tab. This test version is not visible to other users and is automatically deleted after one day. During the test, the link to this test module can be shared with other project members so that they can participate in the test. Important: The rights settings in the test version are disabled. So users can perform any transition and see and edit all content block.

After the successful test, the configuration can be published via Create module. In this course, it is displayed how this affects the booked module quota. If no more free modules are available, the new module cannot be published.

The scenario of a configuration adjustment while an module is running is described in detail in the article Modification to a productive module (article follows) .

In this article, only the rough procedure is presented.

Identical to the initial release, the configuration errors and possible problems are checked, and a test should be performed in a temporary test version. After that, however, the procedure in this scenario looks somewhat different:

• If data migrations are necessary, they are listed before the changes are released and must be confirmed. 
• The migration mode is then started. This puts the module into read-only mode and displays a notification message for users. After no more active work is performed in the module by users, the data migration starts. As soon as the migrations have been performed, the module is made available write-protected and the maintenance notice is removed.

Translated with www.DeepL.com/Translator (free version)