2

My dilemma is about the GIT flow.

Let's assume that I have an application that can be deployed differently (staging release, QA release, production release).

Since the application has profiles to be executed as staging version or as production version (it doesn't depend on which branch the executable is) with the same binary, I think it's really useless to create three different deployable branches, but some colleagues think that it is correct because we need to clarify the binary purpose.

What for me is wrong is that once you checked out the staging branch, you have to force the deploy as staging (it is still possible to select the production version). This problem isn't possible to avoid, so I think that the three deployable branches aren't useful

This is the state they are thinking about:

  • branch master : binary + all profiles
  • branch staging : same master sources
  • branch qa : same master sources

They just want to keep the ideas ordered (I don't think so)

Are both right?

Improve this question
7
  • 1
    I'm not sure I understand this. It sounds like they are fragmenting their code base just so they don't have to configure it before using it. Is that really what's happening? Cause, yeah that's crazy.
    – candied_orange
    Jan 18, 2016 at 14:18
  • I actually am facing some similar problems and working through them myself and interested in the opinions of others. Sadly asking for opinions can start more discussion and debate rather than focus on an answer. Can you reword this into a specific question perhaps?
    – Akira71
    Jan 18, 2016 at 14:19
  • @CandiedOrange it is already fragmented, but all the configurations are now into the master branch. They want to duplicate the master branch into two new ones, without changing the code.
    – Luca D'Alberti
    Jan 18, 2016 at 14:19
  • Then what are they changing if not the code? "Clarify the binary purpose" is a mystery to me if the code is the same. Hell clarify the binary purpose by changing the filename of the executable produced. Am I missing something?
    – candied_orange
    Jan 18, 2016 at 14:25
  • 2
    I do not understand this question.
    – Tulains Córdova
    Jan 18, 2016 at 14:37

1 Answer 1

Reset to default
2

You deploy the branch you need to where you need to.

Now, obviously you aren't going to deploy a feature branch to production. But deploying the latest build from Master to development shouldn't be a problem.

The development branch in git-flow is about being the mainline - that from which the normal process has you branching off of and merging too. The only exception to this process is that of the hotfix branch where you need to grab the current from production.

Lets look at that hotfix a bit more and consider what the deployment process would be when you have three locations. You probably would deploy the fresh hot fix to dev, make some commits on that branch, and then deploy that to QA and then to prod.

For a normal release process with git-flow you are likely to be having builds off of the development server on development branch. Once you branch for release, you will likely have the head of the branch be going to the development server (so the devs working on the release effort can see what the current state is), and specific tagged branches going to QA. Once QA oks one of the tagged builds, the release branch at that tag gets merged into master and then master is tagged and deployed to production.

You will probably want to have multiple environments for dev. The head of release is one deployment environment, head of development is another deployment environment, and maybe even a head of feature being another one or five.

You should be able to build any branch for any deployment environment profile. Deploying the current production to the dev server should be doable.

Git-flow itself is orthogonal to where you deploy things. It is about making sure that the different branches have a limited and defined set of roles that they take. By limiting the roles it makes it easier to reason about what each branch is doing and what its state is at any given time.

The only thing that git-flow tries to say about where specific things are deployed is that the head of master is production. Anything else about what you deploy where in your environment is a site specific issue. Git-flow works just as well with only one production and devs doing all other deployments to their local servers as it does for having production, staging, qa, dev, and dozens of feature servers.

The steps for doing a deployment to any specific server are completely up to the local workflow for that server.

Improve this answer
3
  • What I'm saying is that the possibility to build the binary for production checking out the QA branch is not so clear as they want. I know it's right, but the only limitation new branches are going to make is the name, nothing else
    – Luca D'Alberti
    Jan 18, 2016 at 15:30
  • @LucaD that is an issue of the specifics for how you create a build and isn't something that git-flow says anything about. git-flow is only speaking to the role that a given branch has.
    – user40980
    Jan 18, 2016 at 15:34
  • @LucaD one of the things I've often cited is Advanced SCM Branching Strategies by Stephen Vance. And while it speaks more to a centralized server of perforce or svn, the idea of roles that it presents is what git-flow seems to incorporate. I've found that reading that white paper can help in understanding the philosophy behind each role. Note that the git-flow mainline is development, not the trunk/master.
    – user40980
    Jan 18, 2016 at 15:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.