We don't always get to start with a clean slate, but inheriting a monolithic application doesn't mean you're stuck in that space. Using composer packages, we can break down a monolithic application piece by piece, and using private package repositories keeps the project IP confidential. In this talk, we'll go over how to evaluate a project for packaging, how to set up private package repositories, and how to move forward in a way that won't stop your feature development while you're making these changes. We will touch on the importance of SemVer and how to make sure the packages account for PHP's handling of version numbers.
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
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
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
👍
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.
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).
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
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
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.
