Continuous Delivery

What is a stream team, who is involved, who is not involved and where are they in the organisation.

Stream teams create products. But there needs to be a continuous focus on ensuring that they are headed in the right direction. We examine the daily, weekly, monthly and quarterly activities of stream teams.

It can be hard to identify where to make changes and how to approach it. We'll look at how you can convert ideas into action.

The team is responsible for their way of working. This means that they control how they work and any changes that they want to take on. There is no need for centralised sign-off.

An introduction to the course on how product teams tackle architecture and development in an iterative fashion.

It would be great if we could assume that every team will agree on everything. But this isn't the case. While teams should try to solve issues internally, there needs to be a process for conflict resolution.

Teams should adopt a serverless-first approach to all new development to take advantage of the new capabilities available in cloud computing. But this requires a new way of thinking about how you design systems.

Teams shouldn't wait for regulation like GDPR and CCPA, earning customers trust and protecting their privacy needs to be built in.

Data breaches are becoming more common, and having a larger impact on companies. We look at the ways that teams can build security in.

Accessible designs are better for everyone. We cover some of the more common accessibility tools and techniques.

It's great to be able to start with a greenfields system. But most of the time we are working with legacy systems. We look at some of the patterns that teams use to incrementally migrate legacy systems onto cloud platforms to take advantage of the benefits of cloud.

Big Design Up Front (BDUF) is an anti-pattern. But so is no design. We look at the ways that product teams can achieve the benefits of design without the overhead and waste of BDUF's.

In an ideal world every system would be perfectly documented. However this never happens, and it wouldn't explain the complexity inherent in the code. Code is developed over time and is the cumulation of many decisions. Creating a stream of decisions is more useful for people trying to reason with the current state of a system.

There is a lot of boilerplate that is required to build modern apps. And yet, we want our teams to focus on the differentiating aspects of our product. Using Wardley Maps we show how teams can put more structure into the build-versus-buy debate.

A lot of companies have policies in place to review designs before development starts. However, this would become a bottleneck for teams. We look at the purpose behind the reviews and how teams can achieve similar results.

You need to know how users are using your products in order to figure out if there are gaps in your understanding of user behaviour.

Building code that doesn't deliver user value is a waste. except for your automated pipeline. This is where teams should start their efforts when working on a new product (or updating an existing one). The amount of time saved once the test and release plumbing is in place will vastly outweigh the initial effort.

Whether it is "Merge hell", where you spend hours or more trying to merge in your latest branch, or the continual rebasing effort required to keep branches in sync, branches cause a lot of pain, and wasted effort, for teams.

Some features can't be developed in a day. So how can you do Trunk Based Development with partially completed work? Feature Toggles! We'll look at the different types of toggles and when to use each.

One of the key tenets of Trunk Based Development is that you need to be able to release main at any point in time. It is not possible to run manual test cycles on each commit so automated testing is critical. We look at the best practices for automated testing.

Not everything can be tested through automation. And some edge cases can be tricky to find. This is where exploratory testing comes in. We discuss how and why you should invest in exploratory testing.

Keeping test environments in sync is a big challenge. With cloud infrastructure, we can make idempotent environments which helps alleviate some of the problems. But we can even go one step further - testing in live. We'll look at the pro's and con's of each approach.

We discuss the purpose of a Change Advisory Board and how to achieve the same benefits in high change environments.

Another way of increasing safety is to enable staged rollouts. By limiting the audience for a feature, and with automated monitoring in place, teams can quickly identify if there are any issues and roll back immediately should any issues arise.

Many of our great ideas end up actually hurting our products. A/B testing provides a way of validating the effectiveness of a new feature in a controlled way. Using insights we can decide to pause a rollout until outcomes meet expected targets.

Distributed systems are only going to become more common. Which means that failure analysis is more difficult to reason through. Observability helps teams to diagnose problems and reduces the stress of production monitoring.

Define your SLO's and configure alerts for the most pressing customer-facing metrics.

You build it you run it. It isn't a way to annoy developers by putting them on call but a way of making sure that developers invest in making sure that their services are stable and easily debuggable.

Things will inevitably go wrong. It is important to have agreed structures and processes in place for how to effectively triage issues when they arise.

After you fixed an issue it is important to ensure that everyone understands the root cause. This often involves scratching deeper than the most prominent symptom. And in order to do it effectively you need to remove blame from the equation.