Modifying the schema of a production database is hard. If something goes wrong, the impact on both customers and the team can be enormous. And it can be hard or even impossible to rollback a database schema change if things go wrong. And the same is true for any architectural change for a production application.

The Branch by Abstraction and Strangler Pattern makes significant application changes easier. Are there any similar patterns we can use to make production database changes less risky?

Indeed, there are. The Expand/Collapse pattern is a blueprint for making the database migration. It makes the remodelling both reversible and safe. By expanding the application to accommodate both the old and the new schemas in parallel, we can give ourselves time to:

• Migrate any downstream dependencies on the old database schema
• Gain confidence that the migration is safe

We contract the application to the new version, once we’ve satisfied that the old schema is no longer needed.

The pattern helps to make significant, but necessary refactorings to your data model in a continuous delivery way. Most importantly, without threatening the robustness of your production applications.

While working with our product, I’ve successfully applied this pattern to make major changes to the core of the application, all while serving customers in production. I’ve learned some important lessons about how to best implement the Expand/Contract pattern.

In this session, I’ll share my experiences on how to avoid pitfalls and succeed at these kinds of major data remodelling with hardly any downtime.

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:

• Why are we building what we are building? i.e., Goal(s) of the product
• Who we think are the actors who’ll get impacted?
• How do we expect to change the actors’ behavior?
• What are we going to do to create the impacts? i.e. the feature list / deliverables

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:

• Ad-hoc planning
• Wrong Assumptions
• Pet features

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 made me think about the real goals my product has to achieve during the initial launch.”
• “Wow, this is a great way of visualizing”

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:

• Mainline Development
• Feature Toggles
• Build Automation
• Deployment Automation

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.