3 ms·

I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and yo

I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and you're expected to take just those issues from 'develop' (or somewhere) and get them over in to a 'release' branch of the current released code. I now tend to keep local branches of anything I worked on for months, because 4-6 weeks after it was approved/merged (and deleted) in to 'develop', I may have to also do a 'hot patch' on to a release branch, and cherry picking is the proscribed way of doing it.

justinclift 6y ago
That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
- mgkimsal 6y ago
  I think it possibly did a few years ago. There's a lot of 'tribal knowledge' stuff, and none of these practices were explained when my team (another... 8ish people) were added to the current team months ago. I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.

3 ms·

I'm on a project and it's the opposite. Full releases every... 2 months give or take, but every... week or two, there's a round up of 'critical' issues, and yo

by mgkimsal 6y ago

justinclift 6y ago
That sounds fairly disorganised and nightmare-ish. In practise though, does it work well?
- mgkimsal 6y ago
  I think it possibly did a few years ago. There's a lot of 'tribal knowledge' stuff, and none of these practices were explained when my team (another... 8ish people) were added to the current team months ago. I think it could be done a lot differently, and better, but any change requires huge amount of political changes. There's probably ... 2 or 3 teams that would need to approve of any process change, and no one wants to be the one to push changes like this ahead. It's "good enough", even though... we often collectively lose a non-trivial amount of time every week or two or three. We log that "wasted time" in a spreadsheet to make a point of it, but... no one is motivated enough the shepherd the required change process. The devops team would have to change a bunch of their scripts, and the process would need to be coordinated among multiple teams of varying sizes and skills. It is kinda disorganized and nightmarish with... I'm trying to count - there's maybe 20+ devs touching this. I suspect this was 'fine' 10 years ago with, say, 5-6 devs who would have dealt with it.