Code Freeze, Recompile and Code generations - stuff thats not that scary with CD

· November 2, 2012

Sure enough… There’s an abbreviation for Continuous Delivery. It’s CD.  I think this means that it’s important :)

The last couple of days I’ve run into a lot of expressions, true-isms and problems that we take for granted that is turned a bit on their heads when looking into releasing often. And with often I mean real often - like all the time. No really I mean continuous delivering.

Yes, I know that if first feel a bit scary and unachievable  but in this blog post I’ll try to show you a couple of things that make that strive worthwhile. I think

Continuous Delivery?

| | |:————————————————————————————————:| | | | From Industrial Logic |

So the short and sweet introduction is really this; push EVERY change to your code, configuration and environment to production. Do that all the time.

To unwrap that it of course mean that you need to have you code, configuration and environment managed in a way that allows for these rapid kind of changes.

Your artefacts needs to be version controlled for starters. Yes, even the environment and configuration to it. So that you easily can roll it out and back again if needed.

The build, test and deployment process needs to be automated. Yes, even the testing and deployment. Otherwise you’ll bore your team down within the first 2 hours of the systems lifetime.

The quality of everything needs our highest attention. Yes, a broken build is not acceptable. As I heard Jez Humble say: “In a Continuous delivery team the highest priority is not getting new features out, it’s keeping the system in a deployable state.” All the time.

This is quite hard to achieve. Yes, but it’s worth it. Stay with me.

A thought experiment

| | |:----------------------------------------------------------------------------------------------:| | | | Switch | When faced with hard stuff I like to flip the coin and see a world where the problem was solved all ready. I picked this up from the excellent book Switch: How to Change Things When Change Is Hard. And a little bit from Lean and the Toyota Kata.

What got Toyota to think differently about optimising for flow and minimising WIP in a time when everybody else went for mass production and optimising for resource allocation? Probably the fact that they were bombed to pieces. They didn't have any stocks, nor money to keep one. They could only build cars for the people that order them and hence needed them to flow fast from order to finished product. It didn't for starters but that was what they needed to do.

So they flipped the way they thought about the problem: we need to be here \[future idealised state\]. How do we get there? Let's try some different experiments to see if we get closer or further away from that.

Ok - of on tangent here. But the idea to think about an ideal future and see how wonderful everything would be there, to then try to get there.

So, imagine that you had continuous delivery in place for your system. Just imagine all the things that used to be big problems, things that you avoided and thought of as bad - what would happen with them. Here's a couple of once that I've thought of lately: ### The problems #### Code freeze | | |:-------------------------------------------------------------------------------------:| | | | From Meme Generator | Code Freeze - oh how I hate that phrase. You know the one: "Ok - people. 2 weeks left to release. No-one touches the code! I declare Code Freeze!" When that's utter these days I say something like: "Great then we all can go home. Let's go!". Because it's never true. You still touch the code. Of course. But now you do it with a bad conscience.  And for the code you change you have to go through a Change board of sorts... Yes I know. I don't want that either. Imagine that every change is deployed. You deploy several times a day. There is no code freeze in such context. Code changing is the way you roll. It's supposed to be changed. It's built to be changed. Often. The way we've constructed our build-test-deploy-pipeline will help us keep it good and safe. #### Recompile | | |:------------------------------------------------------------------------------------:| | | | From http://fixitwizkid.com/ | I remember when we wrote lots of code, in strange ways, just to avoid recompilation.  We created strange tables (Id, Key, Value) that allowed us to add columns. Just to **avoid** recompiling our code. And got horrors to maintain. We put more and more information, even business rules or stored procedures, so that we could change it without recompiling and deploy. Brrr - I shiver at the thought. But, mind you well, recompilation of big system are expensive under some circumstances. Just getting hold of the code, doing regression tests of the complete system could make any release manager to start crying, right? > "No, please. No more. Don't change that code any more. Hands off!" Imagine that a recompilation was free. And deploy is done as part of normal procedure at least several times a day. We take pride in being able to change our system often and securely. Recompilation, testing and deployment should just be a shrug of your shoulders, not a shiver down your spine. #### Code generation Code generation has long been frowned upon. And often for good reasons. I'm not saying that it's the best thing since sliced bread but it can be much nice to handle. You know what I'm talking about; building out a typed set of classes for every table in the database (just to mention something I've done a couple of years ago). We hated that functionality after awhile. Because we needed to recompile and re-deploy it every time we changed something in the database. Something that we didn't wanted in periods of code freeze. Or just thinking about recompiling the thing. Brrr. This code generation (if you wanted it) is of course also part of your deployment pipeline. That get's run every time somebody changes something. And now the problem is not so big or scary anymore. ### Summary Well that was just three short examples that popped into my head when I started to think about this. Please don't read this as a silver bullet or understand it as I'm saying that getting continuous delivery into place is something easy. It's really not. For a legacy system it can be really hard work. But I am saying that it's worth it. And a wonderful future is to be had once we get there. This is just taking a few programming related things and looking closer into them. Now... What should we start change in order to move closer to that future?

Share: Twitter, Facebook