BitBucket, who does the Merge?

  • Not sure if this is the right place to post this, but here we go:

    For those of you using BitBucket, Who does your Merge of the branch to production?

    We have a set up where we have one person(not really one person a group), not a Developer, that does our 'move to server' for production moves(this is different step than Bitbucket).  This places the code out where our production scheduler will pick up the package.

    Another person is currently responsible for doing the Merge in BitBucket, this is currently a different team than mine, but a developer.

    There is a push to have there be a developer on my team, currently pegged to be me, that will start to do our Merge's.

    In the past 6 years or so, I've got used to our companies 'separation of duties' as far as moving things into production.  The 'server move' is staying the same, just to be clear.  My issue is having a developer be in change of the Merge to BitBucket.

    How does you company handle this?

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • Thanks for posting your issue and hopefully someone will answer soon.

    This is an automated bump to increase visibility of your question.

  • The big issue for compliance in many orgs is knowing what was done. Not preventing mistakes, but knowing that a mistake was made.

    There are companies who have developers merge code and then it gets deployed to production by the system. It's a de facto deployment by a developer, but since they don't connect to a machine and everything is logged, this should pass any SOX/PCI/etc. audit.

    I would make sure it's a team of people, as you want to go on vacation.

  • I'm trying to get it to be a team, not a developer.  I would prefer it to be the same team that is responsible to do our server moves, it's not just one person.

    I talked to the developer who had been doing all of the Merge's and he said that there is a push to move more responsibilities back to the developer.  I hope that is not the case.  When I was at my prior employer I had 'god' rights to everything and could do anything.  I don't miss having it.  Ok, maybe sometimes it would be handy.

    The thought process here amongst others is that what is merged to master is the 'truth'.  I was making the argument that what is done by the 'server move' is the 'truth' since that is what the scheduler is executing.  And I can agree that 99% of the time they will be the same.  But it's the 1% that I know will bite me or someone else when they are looking into a prod issue and what is in BitBucket doesn't match what was executed by the scheduler.

    -------------------------------------------------------------
    we travel not to escape life but for life not to escape us
    Don't fear failure, fear regret.

  • If you are merging code who is going to know how to resolve any merge conflicts that come up?  In my mind, it seems like a developer will be the most likely one to understand what is going on and how to resolve the merge conflict.  Whatever group is responsible for the code and most likely to be able to resolve any merge conflicts should be responsible for the merging.

  • This was removed by the editor as SPAM

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply