Idea Portal
If you deal with Staging systems like Development => QA => Production you need a Transport System as good as possible.
All changes to the System should belong to a a Change-Package (Change, User-Task - whatever).
This Information should be recorded when Changes are made / committed.
Change-Packages have title and a description
A Change-Package covers everything: Creating a new Database, new Document / Search Class, Scriptings, Roles / Groups, Rights, technical Users, Fips Jobs ... whatever is changed in the System and belongs to the Change Package.
Change-Packages are versioned
Change-Packages can be exported
Changes can be imported to a system
There is a Change History for each CSB (Is this change already applied to the system? Witch Version?)
Changes-Packages can include Scripts which are executed before and/or after a change is applied to a system.
The current Transport System is not really a good fit for this purpose - its more like a poor man's tool which somehow does the job more or less .
I like to give a bit more context on the existing transport service as the basis of our reasoning.
In the transport service you can create transport (definition) packages which is a selection of objects to be transported. An actual transport package (an export of these objects at a point in time) can be created based on that definition. Such a package is then used to be imported into another system. The transport packages are also the basis for fast starters and hence also important beyond staging.
It is also important to understand that we are transporting highly interrelated objects and data structures. This is also the reasons why we cannot support versioning of these elements in Doxis CSB. Though everything is technically somehow possible (but only if it would have been designed from the ground up, which we by design and by choice have not done), versioning of these elements would be pretty uncommon and highly complex. Handling of interconnected versioned objects has even more complex. This, you cannot compare that to versioning of source code.
With that in mind we also cannot just easily transport changes. We transport the state of an object, compare that### and that apply changes in the target system. There is a simulation mode on transport service showing the changes / actions which would be executed.
It could be possible in the future to create a transport package (i.e. export) and to store that as a snapshot and later to create another export and then compare both. Such a mechanism of “versioning” aka history of exports could be possible.
Also, further administrative enhancements like disabling of changes of objects or excluding from a transport might be possible
Though we cannot announce which further enhancements will be done with the existing transport service, the transport service is also very important for an another initiative we will lunch in 2025. Therefore, at least some enhancements are likely to come in 2025.
is there a statement from SER when the "future consideration" takes place?
As Part of this, I also see:
Changes on to-be-transported objects need to be allocated to a change-package before starting and get locked for other changes.
Disable changes on to-be-transported objects in productive systems (not only via authorizations)
Objects need an information that says if it has to be transported or not
All Objects need to be versioned and compareable
For all this, have a look at SAP.