About
Who am I? I work for ThoughtWorks as a technical consultant based in Melbourne, Australia. I make things better, mostly by incremental improvements to code quality, architectural fitness, stability, and safe rapid deployments.
Category Archives: DevOps
DevOps – Ten tips for developers
Last weekend I attended the ThoughtWorks Australia ‘Team Hug’ – a weekend away for all Australian TWers to get together and share ideas and have some fun. On the Saturday we run a conference program. This year we had so … Continue reading
Posted in DevOps, ThoughtWorks
Leave a comment
DevOps and the Iteration Showcase
Look down. Look up again. You’re on the agile team your team could be like. It’s the end of the iteration, and there’s a showcase this afternoon (sprint demo if you prefer) demonstrating all the new functionality the team has … Continue reading
Posted in DevOps, ThoughtWorks
1 Comment
Projects are evil and must be destroyed
The majority of organisations I’ve worked with deliver new system functionality as development projects. These are funded with capex, and have a start and an end. Even projects that are ‘agile’ are still expected to finish at some date in … Continue reading
Posted in DevOps, Software, ThoughtWorks
8 Comments
DevOps Mind Map
In the last couple of years I’ve become very interested in the interactions and collaboration between development and operations teams, the ‘last mile’ of delivering working software into production, and keeping that software healthy and sustainable in production. I’ve had some satisfying experiences working in teams that have bridged part of the divide between development and ops… Continue reading
Build Manifesto
I met a team in the recent past who were adopting automated testing. Developers would write some automated unit tests for their application code, and run them in the IDE before marking their work as complete. Testers would then write down the testing scripts for the completed software, and then manually execute those tests, recording results. An automation tester followed behind, writing automated functional tests from a growing backlog of completed manual tests… Continue reading
Continuous Integration – Ruthless Automation
I think ‘Ruthless’ presents the right intent when automating repetitive tasks – it’s more than just aggressive or compulsive. My previous post talked about deployment repeatability primarily, but our goal is to improve the consistency of all processes that are repeated in the process of creating and maintaining system.
A sequence of actions performed manually multiple times is a surefire recipe for disaster… Continue reading
Posted in DevOps, Software, ThoughtWorks
1 Comment
Continuous Integration – Repeatability
There’s some simple rules to follow to reduce the unexpected – particularly in build and deployment as part of a Continuous Integration process. If something works, I expect it to work again next time, and will put in place something to make sure it happens exactly the same next time. If something fails instead of just fixing it, I want to put something in place to make sure it never happens again. Simple application of these rules can bring calm and order. Continue reading
Posted in DevOps, Software, Tech, ThoughtWorks
2 Comments
Continuous Integration – Commit Frequently
I thought by 2010 that this would be a standard doctrine, but it’s not (at least with the customer teams I coach). Commit regularly – minimum once per hour. Every minute past one hour should make you very uncomfortable. The … Continue reading
Posted in DevOps, Software, ThoughtWorks
1 Comment
Continuous Integration – Single Code Line
A common practice in SCM is to create multiple branches (code lines) from a stable baseline, allow teams to work in isolation on these feature branches until they meet some quality gate. The feature branch can then be merged into the baseline to form a release. I find this approach abhorrent in almost all cases…. Continue reading
Posted in DevOps, Software, Tech, ThoughtWorks
1 Comment
Continuous Integration – If something hurts, do it more often
The prevailing attitude in software development still seems to be that if something is difficult or expensive (or even just not much fun), we try to do it as few times as possible. This usually means deferring it until as late as possible. Continue reading
Posted in DevOps, Software, Tech, ThoughtWorks
1 Comment