MultipleCdDiscussion

From CitconWiki
Revision as of 17:31, 8 February 2013 by Therealbuilddoctor (talk | contribs) (Created page with "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 wa...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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.