Moodle Review Apps / CD pipeline for institution going DevOps

Moodle Review Apps / CD pipeline for institution going DevOps

by Alistair Spark -
Number of replies: 2
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

Hi,

Is anyone using Gitlab Review Apps (https://docs.gitlab.com/ee/ci/review_apps/) as part of their internal Moodle development/testing process? Reviewing our current testing environments, we have a DevOps project going in the organisation and I have a vision of a pipeline where any change is submitted as a new branch in Gitlab and then using Gitlab Review Apps this would create an environment for peer-review & acceptance testing which updates on any additional commits and remains live until merged, which would go to a kubernetes cluster (https://about.gitlab.com/solutions/kubernetes/) generating a new environment closely or loosely based on the Moodle docker dev https://github.com/moodlehq/moodle-docker to have all the tools available to our devs. The main reason for having this on K8s is to have an independent mailhog setup for each Moodle environment.

This is how it would fit into our ideal development / testing environments.

Testing CI Pipeline


I would also expect Moodle site config to be managed as discussed here - https://moodle.org/mod/forum/discuss.php?d=380825


Our testing environments currently lack the tooling to be able to develop, test and deliver quickly and reliably new features/plugins. Since we have a very large instance of Moodle, I'd like to get this in shape and really have the most effective testing pipeline.


Would love to hear of any experiences of an effective pipeline you have or any ideas anyone else have about this.

Average of ratings: -
In reply to Alistair Spark

Re: Moodle Review Apps / CD pipeline for institution going DevOps

by Tomasz Muras -
Picture of Core developers Picture of Plugin developers Picture of Plugins guardians Picture of Translators

Hi Alistair,


I'm afraid I won't help you much - but I like your idea and would like to know if you do set up something that works in practice.

You cover different environment here, let me start with the dev one. I've been setting up dev environments for Moodle based on VirtualBox, LXC and Docker. But since Docker is now the cool kid, I'm thinking about taking https://github.com/moodlehq/moodle-docker and turning it into dev environment. Maybe we can work on it together.

What I would need there is:

* moosh ( https://github.com/moodlehq/moodle-docker/issues/61 )

* support for custom PHP settings ( https://github.com/moodlehq/moodle-docker/issues/62 )

* xdebug

* tideways profiler

* DB server configured for raw performance (at the cost of reliability)


Just like in your diagram, I'd use dev environment with no user's data.


cheers,
Tomek

Average of ratings: -
In reply to Alistair Spark

Re: Moodle Review Apps / CD pipeline for institution going DevOps

by Brian Merritt -
Picture of Particularly helpful Moodlers

Hi Alistair


And University of Kent we have quite a good system set up by my predecessor, Skylar Kelty.


We use gitlab and every commit goes through the review apps and we get a score card and/or pass fail from each for things like linting, style, coding errors etc.  I would like to make more use of the testing capabilities but we are quite busy, so not there just yet in terms of behat testing our own plugins.


We are not deploying from gitlab (we use the https://deployer.org/ to do deployment) but do have a good model of using .gitmodules for all Moodle plugins (each plugin is a separate repository) which makes it easy to both deploy a full Moodle set and also maintain forks of repositories where we either developed it ourselves or needed to modify someone else's plugin.


The development environment runs in Docker, using a combined php & nginx container which mimics our live environment, plus a db container (same) and other tools.  We are not running true devops (maybe one day), but the dev environment is very close to live.


Between live and dev are some demo / test servers which the faculty learning technologist and interested parties access and use to try any new developments, new Moodle releases etc.


We have so far resisted having copies of the live database replicated on demo / test servers.  There are test "modules" which put Moodle through it's paces but having student info is currently a step too far.


Regarding the config.php, we have a suite of configurations specific to platform (live front end, live back end, demo, dev) which get symlinked into place as part of the deployment.


The Moodle platform is quite robust at the moment, so we haven't needed to do load testing.  We have four vms running front end web services, two running cron, scheduled and adhoc tasks, and a dedicated server for uniconv (assessment document processing).  Skylar has worked for over 5 years reducing page load time and performance overhead, and the use of redis has played a major part in helping to keep user performance up.  He also created a shared file structure so that every Moodle year (each Moodle year is a separate deployment here) can rollover modules from other years and where they normally would duplicate content/files we store them all in the one file service.


Gitlab has certainly played a large role in building towards devops, and it will be interesting to see how your adoption goes forward.

Average of ratings: -