/
[composer] Use Composer

[composer] Use Composer

Owned by Alex
Last updated: Jan 28, 2015

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:

  1. 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);
  2. no large svn checkouts (for developers), because all 3rd party libraries are managed by Composer and not in In-Portal repository;
  3. automatic 3rd party library upgrade, because Composer will take care of that;
  4. no need to have "root" access to a server, because Composer installs all libraries locally in project's /vendor/ folder.

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:

Step 1

  1. create account on GitHub (git repository hosting, that is free for OpenSource projects) for Intechnic company
  2. put all In-Portal code (in-portal, open-source modules, themes) there (on GitHub), where each module/theme would be a separated GitHub repository
  3. existing aliases would be empty Git repositories with a composer.phar and composer.json file in them, that would tell what versions of which modules are required
  4. project checkout is easy:
    1. clone a git repository
    2. 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:
    1. put module name into his composer.json file
    2. run "php composer.phar update" to get new module
    3. install module from In-Portal's Admin Console

Step 2

  1. 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
  2. each moved out piece will have it's own release cycle (can get released even before In-Portal does)
  3. all component bug fixes are automatically applied to all projects using it (through usage of Composer "1.*" dependency)
  4. 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