Prompt to merge your branch before deploy?

[qris]

Let's say I'm working on the develop branch and I request a deploy to the staging server, which uses the staging branch.

Most likely I want to merge the develop branch into staging before deploy. I often forget to do that (my fault), so I deploy a no-op. I know that dye prompts me if the branches are different, but we're already logged into the remote server by that time, and all I can do is cancel the deploy, merge, push and deploy again.

The steps that I very often need are:

• git checkout staging
• git pull
• git merge develop
• git push
• fab.py deploy staging
• git checkout develop

Dye could actually prompt me before logging into the remote server, if my current branch is different than the one which will be deployed, whether I should merge into the target branch beforehand. This would save some manual work before each deployment.

Of course, one of these steps might fail, for example I might have local changes that would be lost if I checked out a different branch, or merge conflicts, and I'm fine with Dye aborting in that case and leaving me to sort out the mess.

Does this seem like a reasonable feature? Let me know if so, and I'll try to work up a patch.

[foobacca]

We could check if the local branch matches the default deploy branch for that server before we log into it. But I did the login first so that the script can also check what branch is checked out on the server so that all 3 branches can be reported at the same time (the local branch, the default branch and the server branch). We could first compare the local and default branch, then login and then check the server branch against the other two - we probably wouldn't have to interrupt the user twice very often. (The idea of checking the server branch as well was that you might be using a non-standard branch for a few deploys, say to the dev_server)

I feel nervous about trying to do git merges etc (as they can go wrong in so many interesting ways ...) and it might well be confusing for less experienced users. I'd be a worried that less experienced users might well just enter Y without thinking it through, if we gave them the option.

Also I'd want to confirm that all those git commands will fail with a non-zero exit code under any condition we want to stop at.

Then there's things like uncommitted files. These can lead to merge conflicts that can hard to back out of. You can get more success by doing git stash git stash pop around the git checkout staging; git pull; git merge develop steps - but then if you fail half way through you might not realise some of your files have been stashed and you've lost work without realising it. (This happened to me with some scripts that were clever, mostly worked, but failed and I spent quite a while trying to work out where some of my work had gone until I looked in the stash, and I'm amongst the more advanced git users in Aptivate).

Then there's the question of what question to ask. eg:

You're on a different branch to the the default branch for the staging server (you're on develop and the server defaults to staging). Would you like to:

a) deploy the develop branch?
b) deploy the staging branch in it's current state?
c) automatically merge your develop branch into the staging branch, push that and then deploy the staging branch?
d) name another branch to deploy?
e) abort the deploy now and sort out the branches manually and then start again?

That feels like a pretty complex question.

So currently leaning towards not trying this, though if you have some ideas for good strategies for how to deal with the above I'd be interested to hear them.

[qris]

Regarding what question to ask, some of those options are fairly unlikely and I don't think they need explicit support. The only question I would ask is: do you want to merge your current branch onto the server's branch before you deploy to it (or not, as at present).

If it's too much to roll into the existing deploy command, how about adding a "merge" command that we can run first, if we know what we're doing and are prepared to sort the mess out if it goes wrong (as I am). For example:

fab.py staging merge deploy

would not stash anything, would try to switch branch to staging (aborting if that fails, because I have uncommitted changes for example), pull, merge, push and then deploy as normal. The only complication would be knowing to switch back to the previous branch when the deploy command finishes.

[qris]

I've added some commands to localfab.py in ruforum (commit 7dede5cf1587cf750b766d5a800fca88abd2bb80) which help me to do the things described above (common workflow) with fewer manual steps. Might be worth looking at integrating.