Any thoughts about the integration environments propagation item in the roadmap?

[arheom]

I know there is an item in the roadmap around integration environment propagation, mainly if we have for example 3 environments:
dev, test, prod
the question is how do we propagate something we developed and tested on dev to the other environments?

To brainstorm about it, I see few ideas:

1. we install karavan on each environment, and connect them with different git branches, and we manage what gets deployed to what environment at the git level, through PRs and such from one branch to the other. Then the source code is the same, but the builds are different.
2. we install karavan only on dev. We adapt the build scripts to publish the images and kubernetes deployment files. We run the deployment files to the other environments, like test and prod, independently of karavan. This way we have the same builds and resources, but we dont use anymore karavan outside of the dev environment.
3. we could combine the best options from the above, by extending the karavan web app, like we would have an installation option for karavan for dev mode or deploy mode (as an example). When it is dev mode, it behaves as it is currently, with the difference that when you have multiple environments, the deployment package (images + k8s resources) will be also published. When is running in deploy mode, then all the dev features are disabled, and you only see the deployment tabs and dashboards, so you could accept a deployment package (release) to that environment, which was previously published by the dev mode instance.

As I could not find the answer yet, my question is: the imagined feature will be closer to one of the options above, or something totally different? I would appreciate any indication which would help us set our environment in a similar way, so when it will be released, to not have a big impact on our configuration.

Thanks!

[mgubaidullin]

I think the best practice is to build an immutable container image during build process in dev environment and push to an image registry.
Then this image should be tested on test and if OK deployed to prod. Deployment means simply to apply some resources to k8s.

An idea is to keep in git customized (for test and prod) deployment.yaml generated by build process.
However applying process should be externalized. Karavan should not reinvent deployment tools (Argo, Flux, etc)

[arheom]

Thanks! Sounds good!