Leena S N
A pragmatic & passionate programmer, lean thinker, eXtreme Programming evangelist, hooked into Continuous Delivery and a mother of two lovely angels.
Have you ever wondered how Amazon does deployments in every 11 seconds? Have you ever wondered how frequently Google Chrome updates?
Compare that with an enterprise product you are using or the banking application that you use, it takes weeks or even months for an update. The assumption is that frequent releases are possible for Googles or Amazons or Unicorns. It is not for others.
This talk is about why that assumption is wrong. It can be done anywhere, with enough focus and investment for the Continuous Delivery pipeline to make sure that every commit is releasable or deployable.
And fundamental to Continuous Delivery is Continuous Integration. Continuous Integration guarantees every change committed to the repository is tested and reported about production readiness. And Feature Toggle is for turning features on/off depending upon certain conditions. This opens the opportunity to test certain features quickly with few users for experimentation and learning.
Feature branching has been popular for long, but everyone knows about the “code merge hell”, a common issue because of long-lived branches or infrequent integration. If the team is spending time in fixing the merge hells and checking what part of the code needs to be merged, then it is not the efficient use of human talent.
One common problem any delivery team struggles is to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.
The so called "vision" or "goal" usually rests within Product Manager/Owner or any other stakeholder. There is no forum to converse about these goals or ideas as a team. The planning meetings [iteration or release planning] are supposed to take care of this, but there is no standard guidelines defined which would help to brainstorm these in a typical release/iteration planning meetings.
This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:
Finally, by connecting the deliverables to impacts and goals, a map shows a chain of reasons that leads to feature suggestion.
Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.
If you closely watch the sections in Impact Mapping, what to build i.e. the features or the so called backlog comes only at the end, whereas in the typical planning meeting we usually start with a backlog.
The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns during planning meetings:
The hands on workshop will cover the above mentioned concepts of Impact Mapping in detail along with exercising the same.
Below are a few comments that we received from our customers after being part of the Impact Mapping session:
It does not matter how good our design or architecture is, at the end of the day what matters is whether our code is ready for production. But the question is, how do we make sure that our code is always production ready. As described by Jez Humble [Co-author of Continuous Delivery book] Continuous Delivery [CD] is fast, automated feedback for production readiness of our code when any change that happens to the code, Database, configurations or the infrastructure.
During this workshop, we will give you an overview of Continuous Integration[CI] and Continuous Delivery[CD] and also talk about the key practices of CD such as:
As this will be a “hands-on” session, we will be using Jenkins as an example tool. We will walk you through setting up CD using Jenkins and its Build Pipeline Plugin. We will also briefly touch upon open source tools that help with deployment automation such as Chef/Puppet, Capistrano etc.