Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Composer at Scale, Release and Dependency Management

244 views

Published on

Having one application to support is easy enough, but what if you have a CMS, an API, a design tool, and a core library that each other tool also needs to consume? Where do you even begin juggling the release management and cycle of so many interconnected and interdependent packages? Learn how a small team manages a large CMS project and utilizes real-world best practices of Git, CI/CD, and old fashion planning to bring a solid platform to thousands of editors and millions of viewers.

Published in: Software
  • Be the first to comment

Composer at Scale, Release and Dependency Management

  1. 1. Composer at Scale, Release and Dependency Management Joe Ferguson
  2. 2. Who Am I? Joe Ferguson PHP Developer Engineer @ Aol. Twitter: @JoePFerguson Organizer of @MemphisPHP OSMI Board Member @NomadPHP Lightning Talks Passionate about Community
  3. 3. This is not a Composer Talk
  4. 4. What’s “Scale”?
  5. 5. “At Scale” http://www.pcmag.com/encyclopedia/term/68176/at-scale “…at the required size to solve the problem…”
  6. 6. 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.
  7. 7. Everyone is at “Enterprise” “Scale”
  8. 8. Brands
  9. 9. http://corp.aol.com/mission
  10. 10. Enterprise === A lot http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at- everything.html
  11. 11. We’re a small(ish) team 2 Front End Devs 6 Back end Devs 1 Architect / Product Manager 1 Manager
  12. 12. Foundation of our Applications Modern* Well Tested Semantic Versioning Peer Approval Continuous Integration Client Focused Solutions
  13. 13. Our CMS Application
  14. 14. Start with a strong version control process/strategy
  15. 15. New Feature Git Workflow Pull master branch
  16. 16. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description
  17. 17. New Feature Git Workflow Pull master branch checkout new branch named feature/new-feature-description change code <where the magic happens>
  18. 18. 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
  19. 19. 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>
  20. 20. 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
  21. 21. Commit & Versioning Tools
  22. 22. Emoji in your commits! https://github.com/slashsBin/styleguide-git-commit-message
  23. 23. Commit tool to automate messages https://github.com/jakeasmith/commit
  24. 24. export GIT_EDITOR=~/ PhpstormProjects/commit/bin/commit
  25. 25. Commit tool to automate messages https://github.com/jakeasmith/commit
  26. 26. Identify What Changed
  27. 27. Bump! https://github.com/jakeasmith/bump
  28. 28. $ bump major|minor|patch
  29. 29. Wait for package repo to index new version
  30. 30. Deployment Cycles, Waterfalls, Sprints, Kanban, and bears oh my!
  31. 31. Find what works for you
  32. 32. Kanban Two Week Release Cycle
  33. 33. 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
  34. 34. 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
  35. 35. Production Deployment 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 Tuesday following the RC freeze is production deploy Release branches are Merged into master via same 2 peer approval pull request process
  36. 36. Production Deployment 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 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
  37. 37. When something breaks…
  38. 38. Hotfixes and Bugfixes Hotfixes are branches named hotfix/description that are opened against master Hotfixes are how we patch production
  39. 39. 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
  40. 40. That’s how we deploy features to our CMS
  41. 41. Our CI/CD Hero
  42. 42. 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
  43. 43. That’s how we deploy features to our CMS, API,
  44. 44. That’s how we deploy features to our CMS, API, Design Tool,
  45. 45. That’s how we deploy features to our CMS, API, Design Tool, and other standalone applications
  46. 46. Architecture CMS API Design Tool A lot of shared logic
  47. 47. Enter: “Core”
  48. 48. Architecture CMS API Design Tool Core
  49. 49. composer require aol/core *not the actual package name
  50. 50. Control Version Constraints { "require": { "aol/core": "^17", } }
  51. 51. Lock To A Minor Version { "require": { "aol/core": “^17.10", } }
  52. 52. We now have access to all of the logic in Core in all of our applications
  53. 53. 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)
  54. 54. Architecture CMS API Design Tool Core Version 15.1.3 Version 17.6.13 Version 17.0.0
  55. 55. Remember Scale?
  56. 56. Core is just another application…
  57. 57. “Compromise is essential because there are no ideal solutions, only trade-offs” Thomas Sowell - “A Conflict of Vision”
  58. 58. “Medium” Services
  59. 59. Follow your process
  60. 60. Feedback! https://joind.in/talk/024d5 Joe Ferguson Twitter: @JoePFerguson Email: joe@joeferguson.me Freenode: joepferguson Contact Info:

×