April 10, 2024 at 12:00 am
Comments posted to this topic are about the item The Code Freeze
April 10, 2024 at 8:30 am
I think your point about humans needing a change of pace rings true.
I know it sounds daft but I used to enjoy the excitement that surrounded a major release. The way the delivery lead and service manager would get us all together, rehearse both release and role back, the final adjustments. A release would take place so that when website traffic started to hit at 07:00 everything would be in place. That meant that, depending on the release, this could be anywhere between 02:00 and 06:00. There's something magical about driving into work along a deserted motorway, down onto the Cheshire plane with the refinery flaring off into the night.
At the end of a release the management would buy us all bacon butties and drinks to thank us. It felt like we'd just won a big game after weeks/months of training. Everyone pulling together.
Ultimately, the way things are done now is much better, more reliable, less stressful, in every measurable way it is better. We've designed out the need for a code freeze and turned our processes into white goods and no-one gets excited by a fridge.
April 10, 2024 at 11:10 am
... and no-one gets excited by a fridge.
<Phil looks away, feigning agreement>
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
April 10, 2024 at 2:06 pm
Code freezes are different where I work. They are periods where nothing (apart from emergency fixes) can be deployed due to business constraints, eg. end of year, end of tax year, etc. Development continues as normal, so there's no real change of pace, it's just that the release cycle has been paused.
April 10, 2024 at 3:35 pm
Both at my last job and this job, we had code freezes. At the last job it was tied to billing periods. In my current job, it is tied do the state legislative session (I work for a large state department), which alternates between 30 and 60 days, so it is a long period of time. And we trend to not release during the Christmas/New Years holidays, due to the fact that several people are taking the time off.
However, even though we don't release during the legislative session, we still are very busy. In fact, I wish we did take a break, but we never do. If we release something to production at 10 AM, we go to the next thing at 10:01 AM. There are no breaks, no time to reflect upon what we've accomplished or could have done better, etc.
Kindest Regards, Rod Connect with me on LinkedIn.
April 10, 2024 at 4:42 pm
I think your point about humans needing a change of pace rings true.
I know it sounds daft but I used to enjoy the excitement that surrounded a major release. ...
We've designed out the need for a code freeze and turned our processes into white goods and no-one gets excited by a fridge.
Agreed. I love the stressful, long hours periods around a release or major change. However, those need to be relatively rare.
I also crave some quiet times, to catch up, relax, or just think more. "thinking time" is very underrated, and we need to learn to appreciate (and take advantage ) or a freeze.
April 10, 2024 at 10:18 pm
I think your point about humans needing a change of pace rings true.
At the end of a release the management would buy us all bacon butties and drinks to thank us. It felt like we'd just won a big game after weeks/months of training. Everyone pulling together.
I had to look up a "bacon butty"! 😂😂😂
April 10, 2024 at 10:18 pm
This was removed by the editor as SPAM
April 11, 2024 at 2:10 pm
David.Poole wrote:I think your point about humans needing a change of pace rings true.
I know it sounds daft but I used to enjoy the excitement that surrounded a major release. ...
We've designed out the need for a code freeze and turned our processes into white goods and no-one gets excited by a fridge.
Agreed. I love the stressful, long hours periods around a release or major change. However, those need to be relatively rare.
I also crave some quiet times, to catch up, relax, or just think more. "thinking time" is very underrated, and we need to learn to appreciate (and take advantage ) or a freeze.
David.Poole wrote:I think your point about humans needing a change of pace rings true.
I know it sounds daft but I used to enjoy the excitement that surrounded a major release. ...
We've designed out the need for a code freeze and turned our processes into white goods and no-one gets excited by a fridge.
Agreed. I love the stressful, long hours periods around a release or major change. However, those need to be relatively rare.
I also crave some quiet times, to catch up, relax, or just think more. "thinking time" is very underrated, and we need to learn to appreciate (and take advantage ) or a freeze.
I totally agree with you, Steve! "Thinking time" is badly underrated!!!
Kindest Regards, Rod Connect with me on LinkedIn.
April 11, 2024 at 7:07 pm
David.Poole wrote:I think your point about humans needing a change of pace rings true.
I know it sounds daft but I used to enjoy the excitement that surrounded a major release. ...
We've designed out the need for a code freeze and turned our processes into white goods and no-one gets excited by a fridge.
Agreed. I love the stressful, long hours periods around a release or major change. However, those need to be relatively rare.
I also crave some quiet times, to catch up, relax, or just think more. "thinking time" is very underrated, and we need to learn to appreciate (and take advantage ) or a freeze.
TBH, we do mostly waterfall style major releases along with a mix of small stuff for fixes or improvements. Our releases are not, by any means, "stressful". The "thinking time" we use is in the thoughtful design of the whole shebang even if not designed all in one sitting.
I'm also really glad that we do it this way because there are frequently a lot of dependencies due to the nature of the work we do. As a result, the "users" making the requests don't really know what they want until they see what they don't want but use that to envision "possibilities".
To summarize, CI/CD isn't good for everything.
And, IMHO, what people have been calling DevOps has become a marking term for being stuck in an infinite cycle of CI/CD that sometimes leads to some pretty nasty stuff.
The smart shop will say "It Depends" and realize that one (CI/CD aka Water Torture 😀 ), the other (waterfall aka water boarding), or a combination of both (comfortable shower, IMHO) may be appropriate for any given project.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 12, 2024 at 1:29 pm
When I began my journey towards adopting agile and DevOps ways of working it was an absolute nightmare. Basically DBAs were excluded from the training given to the development teams. We were trying to play catch up and get answers to the questions as to how databases could be handled in an agile way and in a way that was compatible with DevOps ways of working. No-one was able to offer guidance or advice. If anything, the attitude was "if you don't know you are obsolete and irrelevant".
We put a lot of hard work and thought into adoption. We were quick to realise that there was value in what the development teams were adopting, it was just that no-one knew how to apply it in the DB world where you can't just tear everything down for a new release. The data has to be protected and maintained.
We got there in the end though I would caveat that with "for the things over which we had control". I don't know why, but the CDO and CTO seemed to be hostile towards DBAs and data people per se. The fastest way to get the CDO to smile was to give him the opportunity to say no to a data person. That limited the scope of what we could do because, inevitably, you run into upstream/downstream dependencies on the changes you need to make.
The key for us was going in with an open mind despite the temptation to man the barricades against the hostiles.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply