Packaging the Monolith - PHP Tek 2024 (Breaking it down one bite at a time)
- 1. Dana Luther Packaging the Monolith Breaking it down “one bite at a time” @danaluther@phpc.social https://joind.in/talk/5b3d4
- 2. “We can’t upgrade because …”
- 4. What do we gain?
- 5. What do we gain? •Add support for upgraded PHP Versions package by package •Test discrete portions of the code via CI/CD pipeline •Only use the code we actually require in each installation •Grant access to additional personnel / contractors at the package level •Determine which portions of the library are obsolete and no longer in use
- 6. Does this create new challenges?
- 7. Does this create new challenges? •Additional repositories to track •Must implement strict SEMVER •Additional build pipelines to set up and maintain •Expense of packagist.com or … •Complexity of setting up and maintaining Satis
- 9. But … public packages?
- 11. Can I just host the packages myself?
- 12. Can I just host the packages myself? Composer’s documentation on private packages: https://getcomposer.org/doc/articles/handling-private- packages-with-satis.md Or private repositories as package sources: https://getcomposer.org/doc/05-repositories.md#using- private-repositories 👍
- 13. DIY - Pros and Cons
- 14. DIY - Pros and Cons Direct Repository Links: • Complete control over access. • Add and maintain each link in every project or package that depends on this package. • Cannot change the repository source without updating all references. Satis: • Consolidates repo links into a single source reference. • Requires scheduled or triggered builds to recognize new tags. • Requires hosting the generated source fi le. “FREE”
- 15. How do we do it? Slowly and carefully!! One component at a time. Start with discrete components that are easily identi fi ed.
- 16. Where do we start?
- 17. First, map your code
- 18. First, map your code
- 21. Where do we start? •Map out your existing library (if you don’t already have a map) •Find the smallest building blocks - do those fi rst •Prioritize the modules/components/etc. •Don’t refactor the logic or upgrade the PHP version yet! •Update the existing library to leverage each new package as it’s ready (deprecate and extend).
- 22. Create the first package…
- 23. Create the first package… •Create your new repo •Establish namespace for your package - match your target class namespaces.
- 27. Create the first package… •Create your new repo •Establish namespace for your package - match your target class namespaces. •Branch names and SemVer •Create your new library folder structure •Create build pipeline and test suite setup •Import existing tests!
- 28. Create the first package… •Import your old classes, using the new namespace structure •Update your tests to reference the new class namespaces •1.0.0-rc1 tag
- 29. Before: After:
- 30. Update the original monolith.
- 31. Update the original monolith. •Require your new package in your original library •Update the original imported classes •Mark as deprecated •Update to extend from the new version (JIC!) •Add tombstone - You just created a Zombie. •https://slides.com/andysnell/zombie-hunt •Update references to the old class to use the new class
- 34. Rinse … Repeat …
- 35. Great … but now what?
- 37. New package branch/version! •Create 2.x branch for the package repository •Update dev-master alias to 2.x-dev •Update minimum PHP required version to your new target minimum version (if upgrading)
- 39. New package branch/version! •Create 2.x branch for the package repository •Update dev-master alias to 2.x-dev •Update minimum PHP required version to your new target minimum version •Update test suite to run properly on the new PHP version •Don’t refactor* the tests! •Finally … update the codebase to your target PHP version.
- 40. Tag it, rinse and repeat again…
- 41. Complete? Upgrade the core requirements.