I've found this thread very interesting and am grateful for all of the suggestions shared. I will be looking into Capistrano, Ansible, Chef, Composer, Docker, Gerrit, GoCD, Puppet and Tasc. It's been a few years since I last looked into these types of tools so there may now be something to suit my needs.
My situation is a little more complicated than yours because I need to support multiple version of Moodle and multiple versions of plugins in several cases.
One of the things you keep in mind is that the GitHub repositories for 3rd party plugins rarely contain the same code as the released code on moodle.org/plugins. In some cases the code is behind while in other cases it is ahead (i.e. new version in development/testing). Be aware and be careful of this as you can end up breaking plugins and your Moodle site. With very few exceptions, the only git repo that I typically clone is Moodle itself.
What I've done is to setup a directory tree structure and have a bash script that assembles/updates a Moodle site with plugins, as needed. Here is an example of my directory structure which matches where plugins would be placed if in the Moodle directory tree (minus the Plugins directory).
Unlike the rest of the directories below, this is a clone of my Moodle fork repository on GitHub which includes all versions of Moodle so it can easily be switched from one version to another when creating a new site. I can also simply merge recent updates into the code. If I need to create a pull request, I will create separate branche (with tracking enabled!) and push it to my GitHub fork. If the core code gets updated before my modifications are merged into the core code, I can rebase my patch branches to merge changes. If you never plan on submitting fixes for Moodle core code, you can skip having a fork on GitHub to make things a little simpler.
When I create a new Moodle site, I simply copy the files to a new location on my webserver and git checkout the desired MOODLE_XX_STABLE branch. If you do a lot of core patches, you may also want to have your own branch which integrates all of your fixes so that you don't have to wait for fixes to be integrated into the core code.
I put all of my 3rd party plugins under a folder called plugins. They are organized in the same structure as if they were in the directory tree of Moodle making it easy to keep track of the types and locations of plugins. For example:
Inside each of the above directories, I have a directory for each plugin of each version of Moodle. Unlike with Moodle, this is necessary because there is no standard organization of branches in plugins. The main branch in some plugins might be "master" while others, like Configurable Reports, might be CR_23_STABLE.
In this case, there is a release for each version of Moodle the Attendance activity module. However, in cases where a version of the plugin is the same across several versions of Moodle, subsequent directories would actually be symlinks so that I only need to make changes in one place when making modifications:
- plugins/mod/groupchoice23 (symlink to groupchoice22)
- plugins/mod/groupchoice24 (symlink to groupchoice22)
- plugins/mod/groupchoice25 (symlink to groupchoice22)
- plugins/mod/groupchoice26 (symlink to groupchoice22)
- plugins/mod/groupchoice27 (symlink to groupchoice27)
- plugins/mod/groupchoice28 (symlink to groupchoice27)
- plugins/mod/groupchoice29 (symlink to groupchoice27)
My script removes the version number at the end of the plugin's directory name.
Custom/Customized Plugins (optional)
Although not required, I also maintain a separate "cplugins" directory tree at the same level as "plugins" where I put plugins that I've ether developed myself or 3rd party plugins that I've customized. It makes my build script a little more complicated but makes it easier for me to easily see what I need to maintain.
Managing plugin source code
As I previously mentioned, git repos are not consistently reflective of the current stable release on Moodle.org/plugins. What you can do is to setup each of these plugin directories as it's own local repo. Then, each time you download a new version of the plugin, replace the existing code (but not the .git directory) with the new version you downloaded and create a new commit for it. This will enable you to move forward and backwards in versions of the code as needed.
I've tried using git subtrees (not submodules) and run into directory structure issues that I was unable to resolve in an automated way. The advantage of having your plugins separate from your Moodle code is that you can then have a system whereby you can pick and choose which plugins to include into the instance of a particular Moodle site. If designed right, this same system can double as a way to add new plugins into existing instances of Moodle and update existing plugins in a given site.
Even if you maintain only one Moodle site, the ability to create multiple sites can be a real benefit. For example you might want to test a new plugin, a new version of a plugin or a new version of Moodle without impacting your production site.
Save even more time/effort/money the Open Source way
Whenever you customize a 3rd party plugin, depending on the nature of the customization, I encourage you to contribute your modifications back to the original author through a pull request. Some managers will see this as giving away the results of your time and effort but, since you feel are doing the work anyway, little additional effort is required to share the changes back to the author. Explain to him/her the true long term benefit of participating in Open Source.
Think about it. Each time you download a plugin, you are receiving hundreds or even thousands of hours of time and effort that one or more people put into this for free. Why return the favour by sharing your customizations with the author? If the author also thinks this would be a great addition, he/she will integrate the changes into the core plugins code. The best part is that, once integrated into the plugin, your modifications will be perpetually maintained and supported by the author of the plugin and possibly even enhanced over time. The same can be said for Moodle core. This means that, when comes the time for you to upgrade to a newer release of Moodle, the modifications will already be upgraded for you and you won't have to spend any time, money or effort re-applying your changes. It's a win-win situation. You get free maintenance enhancements for the life of the plugin and the Moodle world benefits from your genius and may even raise your awareness of issues you didn't think of before it impacts your users.
In general, I've found many Moodle plugin developers to be very responsive and appreciative and open to most contributions. I've submitted issues, fixes and enhancements to 3rd party plugin developers and seen them integrate the changes into their core code not within years, months or weeks, but often literally days or even hours and occasionally even within minutes of sharing changes with them depending on the complexity of the change. You will only see this in the open source community.
Microsoft, Apple and other large companies? They might require you to pay for a subscription or at the very least charge your credit card just so that you can report an issue to them. In my experience, unless you are a MAJOR client, the response in the end is often something like "This issue may be addressed in a future release". Will it? Think of it from a business perspective. Why fix an issue if you are making money from it being broken? They have shareholders to keep happy.
Imagine if that was the way things went in the Open Source community. Progress would be slowed down to a snails pace. Even if the author of a Moodle plugin has abandoned their project or is too busy to respond, you've got the support of the whole Moodle community to help you out. If you don't like the direction in which a plugin is going, you can fork it yourself and customize it to your hearts content however you loose the benefits and handing off future maintenance and upgrades of your plugin.
I've digressed a little here but the point is that sharing back to the community should also be part of your git workflow.
Additional development tools
On a side note, you might also find the Moodle MDK command line tool to be useful in addition to Moosh previously mentioned in this thread. As part of your QA testing, the Moodle Code Checker plugin can help you get 98% of the way to meeting Moodle coding style guidelines.
Hope you find something useful in all of this.