Posts Tagged ‘continuous delivery’
“If you are not embarrassed by [the first version of your product], youve launched too late!”
I am sure we’ve all been to places where there is a CI server and it’s red and no one is paying any attention to it, at that point you are not doing continuous integration.
…the important follow-on to restoring service is doing recourse analysis and actually working out why that happened and being able to put guards in place to prevent it happening again, which certainly mean tests at some point so that problem can never occur again.
I think one of the primary messages is that continuous delivery is it’s not a zero-sum game. This is why I like to talk about the Flickr example because they are releasing more frequently, the stability of their production systems is also increased.
I worked for the last three years within studios, I was the product manager for our continuous integration and release management tool called “GO” and we were very heavily into that to the extend that we built “Go” using “Go” and when we had a good build of Go it would redeploy itself in order to rebuild itself again
Master Jez on two anti-patterns that are common when creating a deployment pipeline: insufficient parallelization, and over-constraining your pipeline workflow.
- Break down your stories into smaller chunks of work (sometimes referred to as tasks). I have never yet found a large piece of work that I couldn’t split into smaller chunks – usually less than an hour and almost always less than a day – that got me some way towards my goal but kept the system working and releasable. This involves careful analysis, discussion, thought, and discipline. When I can’t see a way to do something incremental in less than a couple of hours, I try spiking out some ideas2. Crucially though, it means I get essential feedback early on as to whether my proposed solution is going to work, or whether it will have unintended consequences for the rest of the system, interfere with what other people are working on, or introduce regressions (this is the motivation for continuous integration.)
- Implement stories in such a way that the user-facing bits are done last. Start with the business logic and the bits further down the stack first. Grow your code using TDD. Check in and merge with mainline regularly. Hook up the UI last3.
- Use branch-by-abstraction to make complex or larger scale changes to to your application incrementally while keeping the system working.
How branch by abstraction worksBranch by abstraction involves making large-scale changes to your system incrementally as follows:
- Create an abstraction over the part of the system that you need to change.
- Refactor the rest of the system to use the abstraction layer.
- Create new classes in your new implementation, and have your abstraction layer delegate to the old or the new classes as required.
- Remove the old implementation.
- Rinse and repeat the previous two steps, shipping your system in the meantime if desired.
- Once the old implementation has been completely replaced, you can remove the abstraction layer if you like.
…the release this week has been a very gratifying experience. Mostly because it was in many respects a non-event. We have a big complex fully fledged enterprise system and if it wasn’t for the fact that we were all tracking news about our release on-line I don’t think that it would have been possible to see a difference in our office between this week the week after our launch, last week the week before or indeed any week for several months in the past. We were still working on stories for the next release, in a couple of weeks time. We were still tracking the production systems and checking for any problems and we were still holding retrospectives about how to do better in future.
via Going live | Dave Farleys Weblog. (He co-wrote the continuous delivery book.)