Hi,
we’re looking for a solution to version configurations within a Continua project:
Within our company, we need to be able to support / maintain old releases and in time, since we may require to adjust our build proces over time. When such event occurs, we need to be able to keep the old build configuration.
The solutions I see are as follow (but not all that charming I guess):
1. Copy / clone a configuration when adjustments are required. Bind the cloned configuration to a specific release (this usually is a separate code branch anyway) and use a naming convention to hint
2. If old versions are maintained using a separate branch, use an if clause in the build process to separate build steps for a release branch and “newer” releases. Downside of this that build stages will become huge and hard to maintain.
Another, maybe even bigger downside of the way configurations are currently stored: Once you save the configuration, all stages are saved and there’s no way to revert to an older version of the configuration. Especially during build configuration development time, this can become risky and we had occasions we deleted important code by accident but already saved the configuration.
What I see nowadays is some teams cloning their build configuration before editting … which is an acceptable workaround but I guess you’re feeling me this is not ideal. This will blow up the list of build configurations and will make it harder to find your project/configuration.
Do you have any interesting workarounds for this or maybe already have some cool solutions on your roadmap to support this?
Kind regards,
Remko Seelig
Hi Remko,
Currently configurations are versioned in the database, however this is primarily to ensure that configuration changes to not interfere with a currently running build. Old configuration versions are cleaned up when they are no longer associated with a build.
We have been planning to provide a way to export and import configurations for some time now. It is no issue to serialise the data as json or xml. However, each configuration is associated with shared items such as repositories and variables. We will need to provide an user interface with options for choosing which of these items to export and also options for dealing with missing or conflicting repositories and variables on the import.
This is quite high on our list of priorities, there are however several high priority items we are working on. Once this feature is available, you will be able to add the configuration files to your own version control system.
Dave, sounds great. We’re looking forward to see this in a future release.
Kind regards,
Remko Seelig