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 master branch, this is where we do our data-to-day changes. 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 branches, but these act more like mutable tags than branches, we never commit directly to them, we only fast-forward them along the master branch to point to the commit that we are releasing.
  • With the Server code, we release manually, but we could 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 master 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.
  • files common to PT and US1 servers (e.g. the cult script) are on the master eternal branch. (this acts the same as the master branch on LSO)
  • files only on PT or US1, (such as config files, certificates etc.) 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 master branch that we are releasing.
• We either release this code manually to the PT server or 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 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.
• This can be released manually using the tag, or 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 release 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 LS master branch needs a branch or tag 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 LS master branch. These branch names can be used to deploy the code to the PT and US1 servers.

summary

There are a few more branches in this approach, but we don't to any merging at all, the 'merging' is done by the deploy scripts to the servers.

Other branches (lso_pt, ls_pt, lso_us1 and ls_us1) are just tags which are fast-forwarded. Again there is no merging.

This approach is a bit verbose to describe (diagrams might help), but is very simple in principle and will make releases much easier.

Postcript I note that although Lacuna-Web-Client and Lacuna-Assets are deployed using web-hooks, that we actually manually release the Lacuna-Server code. We may decide to continue deploying the LS code manually rather than using webhooks, but the basic principle remains the same.