There is dependency manager for PHP called Composer (see http://getcomposer.org/). It allows you to keep only main project code in repository and download all used libraries from GitHub when project is deployed to a server.
I see following benefits of using it:
- no need to invent the wheel, because we can use any library out there that fits our needs (need to check out library licensing though);
- no large svn checkouts (for developers), because all 3rd party libraries are managed by Composer and not in In-Portal repository;
- automatic 3rd party library upgrade, because Composer will take care of that;
- no need to have "root" access to a server, because Composer installs all libraries locally in project's
To make this even more interesting I'm proposing to develop new In-Portal functionality (when possible) in a way of pluggable 3rd party library. Such libraries then can be reused even without In-Portal itself.
Separating In-Portal into Components
Right now there is a lot of code in In-Portal and it's modules. Codebase is separated into 2 groups:
- loosely coupled - code can work outside In-Portal (e.g. CurlHelper, ImageHelper)
- tightly coupled - code can't work outside In-Portal (e.g. ScheduledTaskEventHandler)
In-Portal releases also take a lot time to happen (1-2 months and up) because of way how decision is made whatever to create release or not. Right now we delay release until by our subjective opinion (as a release managers) we think, that all possible bugs were fixed. If a new bug is found then release is delayed to make this bug fix fit into release for greater benefit. This concept on a large codebase results in long release cycle which is bad in either case.
What I'm proposing:
- create account on GitHub (git repository hosting, that is free for OpenSource projects) for Intechnic company
- put all In-Portal code (in-portal, open-source modules, themes) there (on GitHub), where each module/theme would be a separated GitHub repository
- existing aliases would be empty Git repositories with a
composer.jsonfile in them, that would tell what versions of which modules are required
- project checkout is easy:
- clone a git repository
- run "
php composer.phar install" command
By doing so we'll get (at least these):
- all In-Portal code accessible and searchable on GitHub, which is already good
- anyone having composer in their In-Portal installation could install a new module with 3 steps:
- put module name into his
- run "
php composer.phar update" to get new module
- install module from In-Portal's Admin Console
- put module name into his
- move out loosely coupled reusable code into it's own GitHub repository (repository per-piece), e.g. ImageHelper goes to one repository and CurlHelper goes to other
- each moved out piece will have it's own release cycle (can get released even before In-Portal does)
- all component bug fixes are automatically applied to all projects using it (through usage of Composer "
- as any code, hosted on GitHub we'll also be granted with usage of TravisCI (https://travis-ci.org/), which is Continuous Integration server, that would automatically run our tests (or whatever we need to run) on every commit.
After completing this step we'll get (at lease these):
- smaller In-Portal codebase
- separate components, that are:
- easier to test
- can be reused in other projects (even ones, not using In-Portal)
- immediate bug fixes without waiting for large module release, that is using component with a bug