MultipleCdDiscussion
Topics:
- CD Adoption Experience
- Problems Adopting CD
- Why Adopt CD?
[Peep means I can't read your name badge]
Tom: Cointinuous Delivery means you can deliver when you want to, without a shitstorm.
Erik: Can I release every commit?
Jason: Do I desire that?
Tom: End users get annoyed by reinstalls -an organisation should be able to choose release candence for user convenience.
Peep: Users in banks get pissed off by UI changes in online banking.
Jason: Reduce transaction cost of release for the producer, but take into account the consumption transaction cost.
Rene: You need to manage the consumer expectations; they wouldn't notice a well conceived change.
Jason: How do I reduce the consumer transaction cost
Andrew: our customers are pulling features.
PJ: stay on topic!
James: (I paraphrase) Continuous Delivery is a superset of Continuous Deployment
Tom: decouple release and deployment.
Marko: feedback and responsibiity. It changes the organisation and the way they deliver software
Asif: Think about it all from the customer point of view - pulling features.
Rene: CD gets rid of release buses - smaller batch size and frequent delivery, rather than shoehorning code into releases, with ad-hoc channels into delivery
Asif: Why would we put effort into features if they aren't wanted?
Jason: Let's take Rene's comments as to a reason why you would adopt CD. Customers say they it takes too long, but it costs too much.
Jason: Who has seen people bypass their internal IT organisation?
Me: Who has seen that go down in flames?
Rene: Holding cost of not delivering features
Andrew: We want to reduce risk.
Jason: Most people think their risk level is appropriate
Rene: We talk about build and CI, but do we design our software to stand up to load?
Tom: Very few people understand the full end-to-end release process.
Me: Most organisations think they are done when they've cut the ode.
Rene: the business think in a waterfall fashion
Jason: people don't understand the connections between things
Tom: do people understand what the other passengers on the release bus are up to?
Marko: Bit Telco made a scrum team be the team that did the devopsy stuff, and slowly turned it around.
Nigel: CD process driven by increasing scale and horrible quality
Jason: People adapt slowly
Marko: If the team around you aren't interested in improving, you won't be.
Jason: Does a cucumber cucumber the other cucumber, or does it get pickled?
PJ: We go in cycles: XP, Duval, Humble, there's always a silver buller
Martyn: managers go buy the tool, not the behaviour
Rene: CD is not tools
[I lost some changes to fat fingers]
Jennie: we deliver slower but we never need to do a patch releases. We do 40-50 builds a day but integrate slowly with a waterfall vendor. Slow down to speed up.
Devesh: testers pair on that project at the beginning, which slows down but raises quality
Rene: there's no point in going fast if things fall off the conveyor belt. Rather have a slower high qulity
Jennie: (answering what does quality mean) We start with failing ATDD tests when we add a feature. Our testers do the deployments into production. Devesh is tester, scrummaster, coder, PM. The testers are the glue that hold the teams together.
Traditional testing skill do not work in CD
Andrew: you're describing what used to be BA's above.
Gavin: hard to get traditional testers to work in a new way (hard to get testers using junit, etc.) testers don't know where to test
Nigel: they started by mking developers responsible and backfilling tester-developers
Jason: unfair to drop this on testers without guidance
Margaret: it's testers who get kicked, so it's hard to ask them to change their job
Andrew: I don't want to see a tester run a test manually twice. And we provide a coach to help the testers move up the stack.
Margaret: it's hard enough to get testers with FS experience, let alone those who will work this way
Jennie: we have people write cucumber scenarios first and let the developers implement the step defs (I paraphrase). My entire testing team is outsourced and we put energy into the vendor releationshop and training the outsourced testers
Jason: I've seen companies pay out contracts for testers but not use them.
Marko: we need to rebrand testing to make it fit CD
Rene: they need a common language, which is why cucumber works
Devesh: you MUST embed testers in agile teams.
Jason: issues that we see with siloed testers is a mirror of your organisation.
Rene: isn't this conways's law?
Jason: if the problem is big enough, you have to deal with large, but smaller problems to deal with first. This helps turn fantasy (doing CD) into reality
Jennie: manual build failures are a real cost that drives CD, and builds trust.
Jason: fix a few things in an organisation and get the people who have fixed stuff to talk
Jennie: in the pub
Tom: development teams were pushing code faster than a waterfall systems team could handle. You have to pay off the pbasics (building daily, good tests) to be able to release daily.
Rene: what would the world look like without Jez's book?
Chris: how does this work for one person?
Andrew: the whol thing is about reducing the transaction costs.
