Admin Thoughts

Admin thoughts

• The build process could perhaps be simplified. e.g. have a non-overlapping repository. All common code would be in the LSO repository, specific code for the environments (PT or US1), for example config or Cult code, would be in a separate repository. Most updates to the PT or US1 might then just be an update of the LSO code without a need to do merging across repositories.
• Do we need to do anything better with the admin screens, or are they good enough?

Proposal for build procedure.

• We retain the two repositories, Lacuna-Server-Open (LSO) and Lacuna-Server (LS) but change the contents and branches slightly.
• LSO contains all of the open-source code (as it does currently)
  • LSO has a 'develop' branch rather like we have now. This is an eternal branch (never deleted) and contains any code we are developing for the next release. This is maintained with a linear history.
  • we also have 'lso_pt' and 'lso_us1' eternal branchs, but these act more like mutable tags than branches, we never commit directly to them, we only fast-forward them along the 'develop' branch to point to the commit that we are releasing.
  • by using github hooks, we can automatically deploy the code to the PT or US1 servers when the relevant branch is modified
  • since we are only moving the 'lso_pt' and 'lso_us1' branches forward along the develop branch to make a release, we can equally move them backwards to quickly revert a release.
• LS is stripped back to remove all code which is the same as in LSO retaining only files which are private and not for public eyes.
  • code such as the cult script
  • configuration files, such as nginx.conf, mime.types, certificates etc.
  • files common to PT and US1 servers (e.g. the cult script) are on a 'private' eternal branch. (this acts the same as the develop branch on LSO)
  • files only on PT or US1, such as config files, are on the eternal 'conf_pt' and 'conf_us1' branches respectively. These branches are totally independent of the 'private' branch and not merged in either direction.
• we may want to move index.html out of the LS repository and put it into the Lacuna-Web-Client (this needs more thought).

So, when we want to make a release we do one of the following.

• If the LSO code has changed (the most common event) we fast-forward the 'lso_pt' branch to the point on the 'develop' branch that we are releasing.
• The github hook detects the change to the 'lso_pt' branch and triggers a deploy of the LSO code to the PT server.

Likewise for the US1 release. That's basically it, no need to merge from LSO to LS, no need to merge between develop and pt branches etc.

• In the event that a PT server config file is changed, the change is committed directly on the 'conf_pt' branch and pushed to the repository.
• A github hook detects the change and deploys it to the PT server
• Likewise for US1 config files on the 'conf_us1' branch.

The LSO deploy script takes care not to write over the LS files and vice versa. LSO and LS can be deployed independently of each other with no problem.

A change to the 'private' branch needs a hook to commit it separately to either PT or US1. To do this we have two branches which act the same as the 'lso_pt' and 'lso_us1' branches do on LSO. These are 'ls_pt' and 'ls_us1', they just fast-forward (or back) along the 'private' branch. Again, github hooks will trigger on these changes and deploy the private code to the respective servers.

summary