Upgrade Every Day

Feedback

1. What’s your struggle?
2. Introduction

Welcome fellow upgrade master!

1. Why am I writing this book?
2. Who is this book for?
3. What can you expect?
4. What not to expect?
5. What if you don’t use PHP?
6. What if your project has the latest and greatest dependencies?

Who am I?

1. Getting closer
2. Finding the trauma
3. Japanese Culture

Why “Upgrade Every day”

1. My first (and last) rewrite
2. What already works in other life areas
3. Compound Effect
4. Change is the only constant

Compound Experience

1. Compound Experience over Single Shot
2. My First Upgrade: A Cautionary Tale
3. Mythbusters

Refactor to Microservices

1. Turning the Tide

Controller-by-Controller Framework Flip

1. What is a Better Way?

Upgrade is Expensive

1. Keeping Codebase Out-of-Date is Expensive
2. Upgrade as an Ordinary Habit

Upgrade Takes Years to Finish

1. Parkinson’s Law

Only the In-House Team Can Handle the Upgrade

You Can’t Upgrade What You Don’t Understand

Upgrade is One Huge Pull Request

1. The Bigger the Changes, the More Risk
2. What is a Better Way?

If it Works, Don’t Touch It

Once We Finish an Upgrade, We Start the Next Upgrade Again

We Lose the Knowledge Base if We Outsource the Upgrade

Our Team Must Have PHP Experts to Make the Upgrade Happen

We Can’t Stop Feature Development for a Year

Upgrade has to happen in one go

1. Prepare
2. Why is preparation so important?
3. Work for a client
4. Pick your project to upgrade

Before we start planning

1. 1. Start with “why”
2. 2. Validate motivation
3. 3. Find client expectations and adjust them to reality
4. 4. Address their fears
5. 5. All-on-board or none

Why outsource the upgrade

1. Thinking Features vs. Thinking Upgrades

Refactoring is not Upgrade

1. What we do when we refactor?
2. What we do when we upgrade?

Under a Year…

1. How to split too big upgrades?
2. What if it takes… 3 years or more?
3. Timebox to activate Occam’s razor

Build Shared Vision

1. How does the project look like after the upgrade?

Two Types of Upgrade

Separate Code and Infrastructure upgrade

1. How far should we jump the PHP versions?

Smallest step Possible

Less is More

1. Reduce, reduce, reduce
2. New tool/package → + maintenance cost

Climbing Huge Mountain

1. Make Safe Spots
2. Staying in the Present Moment - One Move at a Time
3. Take a Break
4. The Mountain Climber Way

Planning the Upgrade

1. Low Hanging Fruit First
2. Rule of Smallest Gap Jump
3. Build on Strong Foundations only
4. Keep having fun

How many hours a week?

1. Too fast, too furious

Think Big

1. Analyse and Plan

Why…?

1. It Protects you
2. It Protects the Client
3. “I already know the codebase, no need for looking into it”

More than Meets the Eye

1. Known problems
2. Unknown forces

Friction Patterns

Difficulty Factor

1. From Pride to Beginners’ Mind
2. Learned Helplessness

Focus Groups

1. 1. General
2. 2. Autoload
3. 3. Testing
4. 4. Static Analysis
5. 5. Continuous Integration
6. 6. Framework-related
7. 7. Database-related

Building Battle Plan

1. Why we need a plan?
2. Real-project Intro Analysis
3. Multi pronged Attack
4. Execute

Before we Execute

CI is the King

1. More than meets the CI? AI

Action: Setup CI Safetynet

1. Trigger in CI
2. 2. Know your PHP version
3. 3. Add composer validate

Deeper Composer Analysis

Spot Deprecations Early

PHPStan Without Levels first

Rector without Rules First

Symfony Service Types before FQNs