Child pages
  • [composer] Use Composer
Skip to end of metadata
Go to start of metadata

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

 

9 Comments

  1. Current commit workflow (FishEye + SVN Repository)

    1. code is commited to SVN repository (source.in-portal.org) with commit message containing JIRA Issue Key (e.g. INP-4335)
    2. FishEye instance (url: http://fisheye.in-portal.org) is polling SVN repository for changes (every 5 minutes)
    3. FishEye detects a commit and, through a FishEye_WebHook (https://confluence.atlassian.com/display/FISHEYE/Configuring+Web+Hooks), informs In-Portal website (url: http://www.in-portal.com) about it
    4. In-Portal website checks if "Fixes ABC-43543 ..." is present in a commit message
    5. if it's present, then it connects to JIRA instance (url: http://jira.in-portal.org) to transition found issue from "Reviewed & Tested" to "Resolved" status
    6. all commits having JIRA Issue Key's in them are displayed in "Source" tab on JIRA Issue page (thanks to "FishEye and JIRA Integration")

    Proposed commit workflow (GitHub)

    1. code is commited to cloned GitHub's repository with commit message containing JIRA Issue Key (e.g. INP-4335)
    2. commit (or multiple commits at once) is pushed to GitHub
    3. GitHub detects a commit and, through a GitHub_WebHook (https://help.github.com/articles/post-receive-hooks), informs In-Portal website (url: http://www.in-portal.com) about it
    4. In-Portal website checks if "Fixes ABC-43543 ..." is present in a commit message
    5. if it's present, then it connects to JIRA instance (url: http://jira.in-portal.org) to transition found issue from "Reviewed & Tested" to "Resolved" status
    6. all commits having JIRA Issue Key's in them are displayed in "Commits" tab on JIRA Issue page (thanks to "JIRA DVCS Connector for Bitbucket and GitHub")
  2. Release workflow

    Here is SVN repository interactions during a release:

    • check if there was no new commit after last release
      • if there wasn't, then:
        • inform release manager of potential problem
      • if there were, then:
        • create new release (set tag)
        • record last commit that we've used to trigger release
        • so "svn export"
        • create zip/tar.gz archives

    With GitHub no much change is required. But beware, that in Git revision numbers aren't incremental (e.g. 1, 444, 443433), but instead are md5 hashes of commit contents. If we do "less then" or "greater then" checks against 2 revision numbers, then we must fix that too.

  3. Migrating existing SVN repository into Git format and importing to GitHub is relatively easy, because Git already have build-in tools, e.g. "git svn ..." commands that allow to simplify conversion process while keeping all commit history, branches and tags.

    This article http://john.albin.net/git/convert-subversion-to-git explains how easy it is, just 7 steps per repository. Of course we can create a script, that would automate even that.

  4. Alex,

    Can you please clarify on this:

    1. no need to have "root" access to a server, because Composer installs all libraries locally in project's /vendor/ folder.

     

     

    1. "root" is name of the user on server, which usually have access to all server. I've probably should have placed quotes to make it look as "root access" instead.

  5. The minimal PHP version required to use the Composer is 5.3.2. Since In-Portal 5.2.x required version is PHP 5.2+, then we can't release Composer support along with In-Portal 5.2.1 release. It would only be possible for In-Portal 5.3.0 release, where supported PHP version will be bumped.

  6. Looking at proposed solution again reveals critical flaw in the plan, that wasn't noticed before: Composer only can install stuff into /vendor/ folder and therefore won't be of much use, because modules have data, that needs to be accessed from the web.