4

Just joined a new company and can only describe the merge process as madness.....is it or am I the one that is mad?!

They have the following branches:

UAT#_Development branch
UAT#_Branch (this kicks of a build to a machine named UAT#)

Each developer has a branch with the # being a number 1 to 6 except 5 which has been reserved for UAT_Testing branch.

They are working on a massive monolith (73 projects), it has direct references to projects with no nuget packages. To build the solution requires building other solutions in a particular order, in short a total fucking mess.

Developer workflow:

Branch from master with a feature or hotfix branch

Make commits to said branch and test manually as there are no automated tests

Push the commits to their UAT#_Development branch, this branch isn't recreated each time and may have differences to all the other UAT#_Development branches.

Once happy create a pull request to merge from UAT#_Development to UAT#_Branch you can approve your own pull request, this kicks off a build and pushes it to a server that is named UAT#.

Developer reviews changes on the UAT# server.

QA team create a UAT/year/month/day branch. Then tell developers to merge their UAT#_branch branches in to the previously created branch, this has to be done in order and that is done through a flurry of emails.

Once all merges are in it then gets pushed to a UAT_Testing branch which kicks off a build, again not a single automated test, and is manually tested by the QA team. If happy they create a release branch named Release/year/month/day and push the changes into it.

A pull request from the release branch is then made to pre-live environment where upon merge a build is kicked off. If that passes testing then a pull request to live is created and the code goes out into production.

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh it's a total mess. I knew when I took on this job it would be a challenge but nothing has prepped me for the scale of the challenge!! My last place it was trunk based development, commit straight to master, build kicks off with automated testing and that just gets pushed through each of the environments, so easy, so simple!

They tell me this all came about because they previously used EntityFramework EDMX models for the database and it caused merge hell.

Comments
  • 3
  • 3
  • 0
    I'm up for trying to drive change but I'm starting to hear from the dev team that management have suppressed them, so I may soon find out I'm powerless to do so despite them bringing me on under the premise they wanted to change!
  • 1
  • 1
    @oceanexplorer If you want change then now is the time. I'd be really clear about the potential for improvements - up to the point where you're almost pushy. Even if you'll end up reiterating what the old crew has been saying management might listen more to someone who is new.
  • 1
    @ihatecomputers Thanks for the advice, yer that's pretty much my angle, I'm a pretty opinionated person about what I believe to be good practices and have become a little pushy, if they don't listen then I will walk. I've had the fortune to work for a great software company who were good at what they do but sadly had started announcing redundancies (public sector cuts) so I jumped. I was hired as a senior dev with the view they wanted to change but I think the development team doesn't have a voice and it is being driven by management, in the wrong direction, it's growth at the expense of quality.

    I won't back down so easily!
  • 1
    @ihatecomputers In relation to the post above, one of the reasons the dev team have raised the flow it that they want to be able to commit changes, have the code built and then be able to preview that build without affecting others. I'd normally just say that they finish a feature, commit to a dev branch and then review the results. I think this stems from the fact they have 0 automated tests, that they want to push to an environment they control to see that it works after a build.

    Not sure on what alternatives I could offer them, I suppose we could do direct builds from a feature branch which then deploy out to:

    http://mywebsite/mybranch/

    I'm used to a much more trunk based development work flow with feature flags to enable and disable code.
  • 0
    @oceanexplorer Sounds like you're on the right track: find out what the actual need is and then fix it in a way that isn't awful.

    In my experience it will have to be a gradual process where you'll work around existing quirks/workflows and not go against the grain too much. When people start to see that the changes you're introducing actually make their lives easier they will get excited about improving stuff and you'll have the support you need to introduce more large-scale changes.

    I like to have an ideal situation in mind and then take baby steps towards that ideal ✌️

    Man, I should implement some of my dev ideas into my life... It's hard to be rational about personal stuff tho 🤓
  • 0
    I gave up reading at around 50%, I couldn't handle more...
Add Comment