composer at scale, release and dependency management
TRANSCRIPT
Composer at Scale, Release and Dependency
ManagementJoe Ferguson
Who Am I?Joe Ferguson
PHP Developer
Engineer @ Aol.
Twitter: @JoePFerguson
Organizer of @MemphisPHP
OSMI Board Member
@NomadPHP Lightning Talks
Passionate about Community
This is not a Composer Talk
What’s “Scale”?
“At Scale”
http://www.pcmag.com/encyclopedia/term/68176/at-scale
“…at the required size to solve the problem…”
What’s “Enterprise”?
http://www.pcmag.com/encyclopedia/term/42637/enterprise
Any undertaking or project, with the implication that it is of reasonable size
and complexity.
Everyone is at “Enterprise” “Scale”
Brands
http://corp.aol.com/mission
Enterprise === A lot
http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html
We’re a small(ish) team
2 Front End Devs
6 Back end Devs
1 Architect / Product Manager
1 Manager
Foundation of our Applications
Modern*
Well Tested
Semantic Versioning
Peer Approval
Continuous Integration
Client Focused Solutions
Our CMS Application
Start with a strong version control process/strategy
New Feature Git Workflow
Pull master branch
New Feature Git Workflow
Pull master branch
checkout new branch named feature/new-feature-description
New Feature Git Workflow
Pull master branch
checkout new branch named feature/new-feature-description
change code <where the magic happens>
New Feature Git Workflow
Pull master branch
checkout new branch named feature/new-feature-description
change code <where the magic happens>
Commit changes and open pull request against the develop branch
New Feature Git Workflow
Pull master branch
checkout new branch named feature/new-feature-description
change code <where the magic happens>
Commit changes and open pull request against the develop branch
Wait for two peers to approve changes <jeopardy theme plays>
New Feature Git Workflow
Pull master branch
checkout new branch named feature/new-feature-description
change code <where the magic happens>
Commit changes and open pull request against the develop branch
Wait for two peers to approve changes <jeopardy theme plays>
Merge pull request into the develop branch
Commit & Versioning Tools
Emoji in your commits!
https://github.com/slashsBin/styleguide-git-commit-message
Commit tool to automate messages
https://github.com/jakeasmith/commit
export GIT_EDITOR=~/PhpstormProjects/commit/bin/commit
Commit tool to automate messages
https://github.com/jakeasmith/commit
Identify What Changed
$ bump major|minor|patch
Wait for package repo to index new version
Deployment Cycles, Waterfalls, Sprints, Kanban, and bears oh my!
Find what works for you
Kanban
Two Week Release Cycle
Code Freeze and Release Branches
Two Week Release Cycle
Wednesday before release is a Release Candidate Code Freeze
Release branches are created from develop branch
Release branches deployed to staging servers
Testing on Staging Servers
Two Week Release Cycle
Wednesday before release is a Release Candidate Code Freeze
Release branches are created from develop branch
Release branches deployed to staging servers
Developers & Clients test changes on staging servers & sign off
From Wednesday to Tuesday is testing time
Production DeploymentTwo Week Release Cycle
Wednesday before release is a Release Candidate Code Freeze
Release branches are created from develop branch
Release branches deployed to staging servers
Developers & Clients test changes on staging servers & sign off
From Wednesday to Tuesday is testing time
Tuesday following the RC freeze is production deploy
Release branches are Merged into master via same 2 peer approval pull request process
Production DeploymentTwo Week Release Cycle
Wednesday before release is a Release Candidate Code Freeze
Release branches are created from develop branch
Release branches deployed to staging servers
Developers & Clients test changes on staging servers & sign off
From Wednesday to Tuesday is testing time
Tuesday following the RC freeze is production deploy
Release branches are Merged into master via same 2 peer approval pull request process
Code is deployed to production
When something breaks…
Hotfixes and Bugfixes
Hotfixes are branches named hotfix/description that are opened against master
Hotfixes are how we patch production
Hotfixes and Bugfixes
Hotfixes are branches named hotfix/description that are opened against master
Hotfixes are how we patch production
Bug fixes are when we find issues after the RC freeze but before RC branch merging to master
Bug fix branches are named bugfix/description that are opened against the release branch
That’s how we deploy features to our CMS
Our CI/CD Hero
Jenkins Automation
Build & Run Tests
Build Docker Images & Test
Build & Deploy Applications
Sound the alarms when something breaks
Slack Notifications in a CI/CD Channel
That’s how we deploy features to our CMS, API,
That’s how we deploy features to our CMS, API, Design Tool,
That’s how we deploy features to our CMS, API, Design Tool, and other standalone applications
Architecture
CMS
API
Design Tool
A lot of shared logic
Enter: “Core”
Architecture
CMS
API
Design Tool
Core
composer require aol/core
*not the actual package name
Control Version Constraints
{ "require": { "aol/core": "^17", }}
Lock To A Minor Version
{ "require": { "aol/core": “^17.10", }}
We now have access to all of the logic in Core in all of our applications
Core Git Workflow
No develop branch
No Hotfixes, or Bugfix branches
All changes are via pull request against master
After PRs are approved and merged version tags are bumped
Semantic versioning is your friend
Individual applications update their own core versions at their own pace (During normal deployment cycles)
Architecture
CMS
API
Design Tool
Core
Version 15.1.3
Version 17.6.13
Version 17.0.0
Remember Scale?
Core is just another application…
“Compromise is essential because there are no ideal solutions, only
trade-offs”
Thomas Sowell - “A Conflict of Vision”
“Medium” Services
Follow your process
Feedback!
https://joind.in/talk/024d5
Joe FergusonTwitter: @JoePFergusonEmail: [email protected]: joepferguson
Contact Info: