Interest registered
We'll be in touch as soon as we have more details on the course.
Continuous Delivery
1 day
Dev, other T-shaped people
Dates Announcing Shortly
Iterative development means that we will need to frequently change the same code. We'll learn the key methods and principles that ensure code remains easy to change.
What you'll learn
- Making code easy to understand
- Easy to use
- Safe to change
- Easy to operate
Modules
1
Continuous Delivery Introduction
0.5 hours of videos
An introduction to the course on how product teams tackle architecture and development in an iterative fashion.
Lessons
Stream Teams
15 minutes
What is a stream team, who is involved, who is not involved and where are they in the organisation.
Ceremonies
15 minutes
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.
Change
10 minutes
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.
Ownership
10 minutes
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.
Introduction
5 minutes
An introduction to the course on how product teams tackle architecture and development in an iterative fashion.
Conflict Resolution
15 minutes
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.
2
Design
3 hours of videos
Since we have broken up our releases into small increments the traditional big design process no longer makes sense. But that doesn't mean we should avoid design. We'll look at the ways to do incremental design within product teams.
Lessons
Serverless First
10 minutes
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.
Privacy
15 minutes
Teams shouldn't wait for regulation like GDPR and CCPA, earning customers trust and protecting their privacy needs to be built in.
Security
15 minutes
Data breaches are becoming more common, and having a larger impact on companies. We look at the ways that teams can build security in.
Accessibility
15 minutes
Accessible designs are better for everyone. We cover some of the more common accessibility tools and techniques.
Migrating Legacy Systems
15 minutes
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.
Design Write Ups
15 minutes
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.
Communication
5 minutes
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.
Build versus Buy
15 minutes
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.
Architecture Review Board
10 minutes
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.
Telemetry
5 minutes
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.
3
Build
1 hours of videos
Code bases are shared, so there is a risk that changes in one team might block another. In this module we will look at the ways that teams can work on shared code bases without blocking and without incurring code merge pain.
Lessons
CI/CD
15 minutes
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.
Branching
10 minutes
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.
Feature Toggles
10 minutes
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.
4
Test
1 hours of videos
Testing is critical for ensuring high quality releases and high customer confidence. The old way of multiple different environments though adds too much waste and delay. We look at how teams can improve the quality of testing without slowing down the pace of delivery.
Lessons
Automated Testing
15 minutes
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.
Exploratory Testing
15 minutes
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.
Test Environments
10 minutes
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.
5
Incremental Releases
1 hours of videos
Even with a great testing cycle things can still go wrong when releasing. The traditional approach is to add more gate checks before release (CAB sign offs etc.). We look at how teams can improve the quality of releases and reduce the risk without slowing down delivery.
Lessons
CAB
5 minutes
We discuss the purpose of a Change Advisory Board and how to achieve the same benefits in high change environments.
Staged Rollout
10 minutes
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.
A/B Testing
15 minutes
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.
6
Operating
1 hours of videos
The merging of Dev and Ops has led to the "You build it, you run it" mantra. We look at the key steps involved in enabling engineers to manage production issues.
Lessons
Observability
5 minutes
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.
Alerts
10 minutes
Define your SLO's and configure alerts for the most pressing customer-facing metrics.
On-Call: Owning Production
10 minutes
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.
Triage
10 minutes
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.
Post Mortem
10 minutes
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.