Last day at #Thoughtworks
Today is my last day at ThoughtWorks, it has been an intense, challenging year.
Monday I will start a new adventure at Forward, I am excited about this as much as I was to join ThoughtWorks the first time in 2006.
I will work with some very talented former colleagues and friends like Mike & Pingles and many others great guys, in a very agile/lean company, I will finally learn Ruby & Clojure and practise continuous deployment…
There’s enough good stuff to keep me busy and happy for a while!
Change the company culture first
I’ve been involved in quite some agile consulting gigs in my work life.
There’s one lesson I want to share: if you want to change an organization you have to change their company culture first.
If you are trying to employ a consultancy firm try to get ready your people to start with, avoid wasting money making sure that your employees are ready to embrace the change.
Make sure that you communicated well and straight that things are gonna change now.
If you are a consultant, make sure that you will have enough slack on the project to work on the company culture, plan, discuss with the client when and how that work will be performed.
Otherwise change won’t work: people will work in micro waterfall iterations, they will use continuous feedbacks to drive others people carriers, they will still micro manage their teams, they will eventually fail and all their effort to “change” and your effort to make them “a better” place to work for will vanish without evident benefits.
The Speckled People
“Maybe your country is only a place you make up in your own mind. Something you dream about and sing about. Maybe it’s not a place on the map at all, but just a story full of people you meet and places you visit, full of books and films you’ve been to. I’m not afraid of being homesick and having no language to live in. I don’t have to be like anyone else. I’m walking on the wall and nobody can stop me.”
— Hugo Hamilton (The Speckled People: A Memoir of a Half-Irish Childhood)
Promote environments not artifacts
Lately I’ve been working quite a lot with environments and release issues.
On my last project we had eight environments: development, continuous integration, test, performance, pre-live and live plus a couple of demo boxes.
This over-engineered situation caused few issues but at the same time made me think and write this blog post 
What we did to improve deployment
Well, automation is the key, even if we are in a windows environment we wrote remote deployment scripts to do remote deploy in the machines using psexec and robocopy.
We template our config files and we have one config per machine.
So far so good, old school good practices.
What still doesn’t work
Your software is done, finished, all the test are passing, unit and integration on the development boxes, acceptance on the CI box, the QA is happy in the testing environment and the product owners are happy on both of the demo boxes, the performance test team is happy on the performance box, the security team is happy with their tests executed on the pre live box.
But still your sofware may not work on live. Or most likely in any of those environments.
Configuration is vital
Your application without configuration doesn’t neither start or with a wrong configuration won’t log or work properly. There’s test coverage on all the aspects of your application but not on environment configuration. You may misspell a name of a server or simply forget that something is different from environment to environment. Your application won’t work as expected.
The configuration of the environment itself may cause serious problems. The most different your live boxes are from your test/integration/performance ones the higher is the risk that your software won’t perform as expected on the target servers.
So, my humble recommendations
Move fast
Moving fast is essential in any aspect of software development, when talking about releasing software is essential that you should be able to continuously deploy and redeploy in a repeatable stable way your application as fast as possible. Use remote scripts, even if you are not working with the cool kids in the ruby world do something similar to what capistrano does.
Have a look on the heroku website for a good example of moving fast…
Reduce as much as possible the number of environments
It’s clear that in the above example we have too many environments, if you have full control ask yourself why do you need them and just take them off. If an environment doesn’t produce any value it’s just a waste of time and resources. Environments can be recycled, most of the applications won’t need two demo environments and a performance environments available for the whole project life-cycle.
How would I cut down the number of environments on my previous example?
Development, continuous integration, test & performance, that’s it, four, it’s a 50% cut down!
A good rule is that your environments should be the same number of your story wall lanes:
- Story in dev > development environment
- Story dev complete > CI environment
- Story in test > test environment
- Story ready to sign off > performance environment
The performance environment can be used as stable build environment for showcases, demonstration of the software and indeed performance tests. But also for one last, more important thing, which is the whole point of this blog post:
Promote environments not artifacts
Imagine that you’re happy with you software, it has been signed off by the product owner and it’s performing well.
Probably you made some changes to the performance environment, maybe you started with a cluster of two machine and ended up with a cluster of four. Now you want to go live, but the live environment that you have is different, you may have some problems.
My idea is to promote the whole environment. You are probably using cloud computing or virtualization, just move this stuff to the live environment, clone it and you are done.
Promote the environment with the artifacts, all together.
Try to define your environments as executable scripts (in the *nix world won’t be that hard) and version control these scripts with your environment configuration, the creation of the whole environment should be scriptable, repeatable and should evolve with your code.
Mark told me that Chris Read has been talking about this stuff for years, you may want to check out his blog or his presentations, he’s anyway way much better than me explaining and making these things real.