We package up the entire moodle source directory with all of our customisations, additional blocks, modules, etc.
We also set the package dependencies (e.g. php5, php5-pgsql
, clamav, freshclam, zip, unzip, etc...). Incidentally, we don't include apache in our dependency listing. This is because we also have a cron server
which is intended to reduce the burden on the frontends and the cron server doesn't require apache (just php). This is something you may wish to consider in the future - it's relatively trivial to implement and it can make a big difference to your frontends.
We typically also have a service package for each class of server. For example:
** Includes the luns-moodle-CUSTOMER package, apache2, etc
** Include the relevant postgres packages
** Includes the luns-moodle-CUSTOMER package, and anything else required
This ties in nicely with our configuration management system. If we need to quickly provision a new frontend, in theory we can create a preseeded debian installer which installs all of the base system config, updates everything, and then installs the service package.
The way that we do things is slightly convoluted, but enables us to easily track the main moodle repositories. You can definitely do this in a much less complicated fashion than we do so but for interests sake, this is what we do:
* Each feature (mod/block/local/theme/etc) is in it's own git
branch based on the latest major release (e.g. all of our features are currently in branches named CUSTOMER-feature-2.2-FRANKENSTYLE_FEATURE based on the v2.2.0 tag).
* We then have a deployment branch (e.g. CUSTOMER-deployment-2.2).
* When we develop a feature, we do so in isolation on it's on branch, after which we checkout the deployment branch and git merge it in.
* We then have a packaging branch (luns-moodle-CUSTOMER-2.2) which is identical to the deployment branch but additionally has the debian packaging files.
* For testing we also have a staging branch which we push directly to a testing server - e.g. CUSTOMER-staging-2.2
An example workflow would be:
# Check out a new branch based on the latest major stable tag v2.2.0
git checkout -b FOO-feature-2.2-mod_example v2.2.0
# write some code here and commit it
git add mod/example
git commit -m 'mod_example Some description for the initial commit (Fixes #123)'
git push lunsprivate FOO-feature-2.2-mod_example
# Merge it into the deployment branch
git checkout FOO-deployment-2.2
git merge lunsprivate/FOO-feature-2.2-mod_example
# Do some testing
# Push the feature to our repository
git push lunsprivate FOO-deployment-2.2
# Check out the packaging branch
git checkout luns-moodle-foo-2.2
# Merge in the new feature
git merge lunsprivate/FOO-deployment-2.2
# Update the debian changelog
git add debian
git commit -m '[debian] Updated to include mod_example'
# Tag the commit
git tag luns-moodle-foo-2.2.1-21
# Push everything to our private repository
git push lunsprivate luns-moodle-foo-2.2
git push --tags --repo=lunsprivate
# Build the package
# Send it to the package server
# On the package server we now include the package
sudo su - aptfarm
reprepro include ~nicols/packages/luns-moodle-foo_2.2.1-21_amd64.changes
# On the servers deploy
sudo aptitude update && sudo aptitude upgrade
For every feature and every bug that we include in the stable deployment, we also create a tracking issue in our issue tracker. This means that when the next major version of moodle comes out, we can go through each issue and make sure that we don't forget any, or introduce any regressions.
It does sound very long and arduous but once you've got the basics together, it actually saves us a lot of time.
If you want any of the above clarifying I can try. As I say, this is a fairly convoluted and I'm aware that we don't do it the easy way. It does have a number of advantages:
* we base features on the latest major stable tag to make life easier when the next one comes out. At this point we take each feature branch in turn and git checkout -b FOO-feature-2.3-mod_example; git rebase v2.3.0; git push lunsprivate FOO-feature-2.3-mod_example. Once each feature branch is complete, we check out the new deployment branch and merge them all.
* each feature can be worked on in isolation
* different developers can work on different features for the same customer very easily (git also makes this easy on the same feature though)
* we can re-use features multiple installations for the same customer
* we can easily apply upstream bug fixes/new features
Any questions, feel free to ask!