Bcn devcon jose luis soria - patterns & antipatterns for delivery

PATTERNS & ANTIPATTERNS
FOR (CONTINUOUS) DELIVERY
Jose Luis Soria Teruel
jlsoria@plainconcepts.com - @jlsoriat

Barcelona, November 9th 2013

Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
Principles behind the Agile Manifesto

How long would it take your
organization to deploy a
change that involves just one
single line of code?
Do you do this on a
repeatable, reliable basis?
Mary & Tom Poppendieck
Implementing Lean Software Development

Done means "released". This implies
ownership of a project right up until it’s in the
hands of the user, and working properly.
There’s none of this "I’ve checked in my code
so it’s done as far as I’m concerned".
James Betteley

Just ship, baby.
Kent Beck, http://www.threeriversinstitute.org/JustShip.html

#1: No model, or random delivery.

#2: Let the operations guys figure out.

#3: Defined and collaborative approach.

Do you exclude from versioning
artifacts like databases,
configuration files, binaries,
documentation, tools or
environments?

That is, do you fail to effectively do the
following, for any needed version of these
artifacts?
Backup.
Get from history.
Undo changes.
Work with other people.
Audit and track changes.
Keep stable copies.
Etc.

Do you manually perform any of these?
Building.
Packaging.
Deploying.
Testing.
Environment provisioning.

Or, do you make mistakes because of missing
steps, misunderstandings, boredom, etc.?
Do you waste time that could be employed in
building and delivering value?
Do you depend on specific people to get these
activities done?
Do accidents frequently happen in your
project?

Do you manually copy or change
configuration files to match each
target environment?

So, do you need to remember which
configuration files must be changed and what
the changes are?
Do you make mistakes or omissions when
doing these changes?
Are you exposing sensitive information about
the environments?

Do you follow a complex
procedure for deployments, with
multiple steps involved?

In other words, do you spend a lot of time
and effort in each deployment?
Do you avoid testing some versions in some
environments because deployment is painful?

ARIANNE 5 FLIGHT 501 EXPLOSION

In 1996, the Ariane 5 rocket was reusing
software from the Ariane 4. Ariane 5’s faster
engines exploited a bug that was not realized
before: the software tried to cram a 64-bit
number into a 16-bit space. 36.7 seconds into
its maiden launch, the self destruct safety
mechanism was activated.
http://en.wikipedia.org/wiki/Ariane_5#Notable_launches

SIBERIAN PIPELINE SABOTAGE
In 1982, CIA introduced a bug into the Soviet
gas pipeline system, that passed preliminary
inspection but made the system fail when in
operation. It led to the largest non-nuclear
explosion ever.
http://en.wikipedia.org/wiki/Siberian_pipeline_sabotage

Do you validate your application
only in development or testing
environments?

That is, do you lack information
about how your application will
behave in the production
environment?

Deploy to a copy
of production.

Do you follow different
procedures for deploying to
different environments?

… making your deployment
procedure is more vulnerable to
environment-specific issues?

Is that procedure poorly tested?

Deploy the same way to every
environment

Do you skip the preparation of
rollback mechanisms before a
deployment?

Or, if a deployment (or the deployed
version) fails, do you need to figure out
how to get the system running again?
Does that take a lot of time and effort?
Is the business losing lots of money
meanwhile?

Have always a rollback
mechanism in place.

Does anyone in your team make
manual changes to the
environments?

…resulting in frequently spoiled or
wasted environments?
Do you have to recreate or reconfigure
them so often?

Does it happen without even noticing,
until it’s too late?

Do you build binaries from the
same code several times during
the release process?

So, do you ship binaries that have not
been tested?
Do you introduce errors because of
different build sequences?

Do you waste time and resources
building the same thing again and again?

Do you fail to gather and
analyzing data about your
delivery process?

Or, do you lack a baseline that
you can use to support
improvement actions?

Do you consistently avoid painful
steps in your delivery process?

And are you leaving sensitive steps
for the last moment?
Do you fail to practice and master
critical aspects of the delivery
sequence?

Do you lack the support of
operations people for defining
the delivery process and
artifacts?

That is, are you not collaborating
with the people that have some
of the key knowledge and
control?

Do you lack a defined,
repeatable, robust and fast
delivery process?

So, are you failing to deliver
effectively?

What about your own patterns & practices?
1. Think about some delivery
practice not covered in the
session.
2. Tweet it.
#bdc13 @jlsoriat
3. Benefit!
http://aka.ms/ReleasePipeline

Thanks! Any questions?
jlsoria@plainconcepts.com
@jlsoriat

http://geeks.ms/blogs/jlsoria
Get my e-book (for free): http://aka.ms/ReleasePipeline
Get the labs: http://aka.ms/ReleasePipeline-HOL
Get these slides: http://slidesha.re/1hVyKvt

Bcn devcon jose luis soria - patterns & antipatterns for delivery

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (7)

Semelhante a Bcn devcon jose luis soria - patterns & antipatterns for delivery

Semelhante a Bcn devcon jose luis soria - patterns & antipatterns for delivery (20)

Mais de Jose Luis Soria

Mais de Jose Luis Soria (20)

Último

Último (20)

Bcn devcon jose luis soria - patterns & antipatterns for delivery