Versions Compared

Version Old Version 3 New Version 4
Changes made by

Alex

Alex

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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)

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