git-flow for multiple staging / production environments

Question

I am trying to apply git-flow for a project with multiple websites that share a same code base.

I currently use many feature branches, one develop branch, one support branch, and MANY production branches: one for each site, since some config files are customized per site.

The git flow tool does not propose many master/production branches, but a single one. What can I do?

Giro

if only changing part in your production branches are configuration parts, you should ideally take those values from environment variables in each production environment. – Bushed

Answer 1

Frankly, this sounds like an application configuration problem -- not a git problem.

We've found ways in our systems to natively support 'overwrite' files -- where the system first looks for a custom file and falls back the default one.

If you can't make your application dynamically customizable at runtime I'd implement a build process that did the overwrites at deploy time.

Hargreaves

Well, yes and no. I know it is not a git problem, but it remains a git flow problem. – Helmand

Suppose you have a web app that is to be deployed in 3 flavors: iphone app, android app, etc. You would need 3 deployment branches, with each one the necessary adaptations of your app for the platform. Now my problem is similar: each website has its own life cycle and version numbers, etc. Moreover, each site is packaged into a debian package for deployment on prod servers. Each of these packages following having their own version bumps. So this is not only about runtime customization. – Helmand

How about considering multiple git repos? A 'library' repo and then a separate repo for each app flavor which import the base library. Though I still think you may be looking at this in the wrong light; the process of packing your app of various deployment types and locations is really a build problem -- not a SCM problem. HTH. – Hargreaves

I would implement Git submodules for the shared library stuff. For example, you have 4 repositories: iphone app repo, android app repo, windows phone app repo, and the shared lib repo. You submodule the shared lib repo into each of the other repos, and that way you can develop and test your shared lib code separately from the specific config stuff in your platform repos. Just a thought. – Rhines

Answer 2

solution 1) develop maven artifacts in subproject and upload them to a custom nexus. then every project of yours can import those artifacts

solution 2) adapt git-flow to your own needs. in our case for example, we have several release-branches and no develop branch. every branch is created from the master. this way we are very flexible and can create short and long-term releases on-the-fly, just by merging all features-branches into a release. this way you could also create special-releases for each of your environment

ps: if you use the git-flow scripts-bundle, then you have to forget about those and do it by yourself (is not so difficult)

Eclat

Answer 3

My solution is the following:

• each environment has its own branch;
• I have a file (pom.xml, in my case. But this is not important) which contains last deployed version for that specific branch.

When I need to deploy, I run a script on my PC that:

• reads the current checked-out branch's name (the branch on which I want to deploy to);
• reads the last deployed version and increments it according to an input parameter (bug, fature,major..);
• creates a tag with {new version}-{environment},
• updates current version in pom.xml;
• pushes all (also tags).

On the server, I run a script that:

• pulls the corresponding branch;
• finds out the tag that describes that branch (git describe --tags);
• checks out that tag;
• stops, compiles, copies, starts.

Inky