We would like an option for the XL CLI to not overwrite an existing environment, but to update one.
Current behaviour: xl apply blindly overwrites an existing environment.
Preferred behaviour: an option / flag to not overwrite, but to add or remove specific components.

The problem is that when working with Devops as Code in combination with the OpenShift plugin, parts of the environment can get lost.

Example of the problem:

Environment gets deployed from yaml file with Devops as Code.
The OpenShift plugin creates a namespace, and adds this to the XL Deploy environment.
The environment is now different from what is specified in the code that was used to create it initially.
If the environment is deployed again - e.g. because an extra infrastructure container needs to be added - this will overwrite the existing environment.
This results in losing the namespace / Infrastructure component added by OpenShift, and deployed applications on the environment.


What we think is a solution:
An extra option or flag for the XL CLI to not overwrite the existing environment, but to modify it.
This way, if extra infrastructure has been added by a plugin, you will not lose it, but will be able to add or remove the part of your choosing.

Doing this is possible via GUI, so we feel it should also be an option via CLI.

Comments

  • Thank you for the idea.
    We've scheduled technical investigation after the Erawan release cycle and are currently anticipating a wider customer base for upvoting this request.

  • We currently do not have a quick fix for this item.

    Currently available option would be: after OpenShift creates the namespace and adds it to the environment, a workaround would involve exporting the YAML and committing it to the Git repository. This approach ensures consistency between Git and the Deploy server.

    However, we recognize the need for a more efficient automation solution.

    During the upcoming Fuji release timeframe, we will be exploring methods to integrate the Deploy server with GitOps.