2

Add a config file with parameters used in install/run script. You can look at Harbor (Github, install docs) as an example of doing just that (and they have a configuration migrator).


2

You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline: Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by ...


1

Key issue with this approach is that applying commits selectively is extremely problematic. Basically, how do you know whether commits are dependent or independent? As you correctly mentioned, this is one of the issues with Gitflow itself, so the solution is shifting methodologies. Preferred way today is Trunk-Based Development (TBD) - https://...


1

In my opinion there should be a staging branch , which holds the production candidate code.And instead of a Test env , have a staging env which will be complete replica of Prod env. In the Staging env the QA can perform their testing and other checks. Dev env = only for developer. Stage env = Replica of Prod and holds production candidate build/code , ...


1

I would suggest adding a job that checks changes in the latest commit and build only that service where some files have been changed.


1

Periodicity will only come into effect if the overall integration and deployment processes take a long time to complete, which is more likely the actual problem. Said differently, in an environment where applications are built using lightweight architectures that are quickly scanned, built, deployed and tested, periodicity would cease to be relevant. I ...


Only top voted, non community-wiki answers of a minimum length are eligible