Thumbnail

11 Good Things about GovCMS

Thumbnail

Si Hobbs

|

Highlighting my favourite aspects of GovCMS reloaded - the Drupal distribution, the platform and the community.

Here are my top likes about GovCMS. A mix of tech and non-tech.

1. Multi-pronged approach to collaboration

GovCMS team work really hard to keep communication channels open both internally between departments and externally with vendors. There are a lot of channels through which people are collaborating: GovCMS Community site, Slack (both GovCMS and Drupal AU), Microsoft Teams, and you'll see them pipe up on various social media. Obviously this is constrained by protocols, but never unnecessarily so.

There is the argument that too many channels can fracture dialog. I don't subscribe to this notion. To be a successful open source venture, it's important to give everyone in government the opportunity to engage regardless of what arbitrary restrictions they have in their organisation.

2. Docker compose

Docker ships as the defacto standard for running GovCMS locally. It is technically possible to run a GovCMS repo in a VM, or Acquia Dev Desktop (eek), you just have to symlink/mount the right bits to the right bits, but I love how docker compose is orchestrating the local build. It means you can run native docker compose commands (just check out the ahoy.yml).

Going with the crowd on this is a good thing. Many developers are already using docker compose locally even if they don't know it, for example Lando generates docker compose files under the hood.

3. The mega meetup

Dating back to Acquian times, I think it's easy to write this meeting off as an excuse to eat sandwiches and cake at the Hellenic Club. It's actually a brilliant and often well-attended event for product champions, decision makers and evaluators to collectively crack hard nuts. The GovCMS team curates speakers and brings in product owners and developers to present on innovation and wins achieved within their departments. This is where the juice flows. (But may I never win another "community participation" award!)

4. Tasks

Just a little thing that we haven't really seen come to fruition. At the moment the two useful tasks that we can run on an environment are cache clear and database backup/download. But there is clearly an abstraction layer for adding new tasks. I have a lot of hope that someone will write a task for creating a merge request from for config changes - sadly way beyond me!

5. GitLab with CI/CD

Definitely the best part of the whole platform for me, the GitLab community edition. It's fantastic to be able to explore the repository and view the CI jobs that are running. And it's brilliant that Drupal.org is using the same platform. This is upstream engagement at its finest.

6. CMI (Features in a good way)

The platform is fairly opinionated about config in Drupal 8, it will just clobber all your config on prod with whatever is in the repo. This is the best default, as it forces all configuration changes to be deployed through CI. That said, you can make quick changes on production, sometimes necessary for operation reasons, you just need to export the database and export the config back into code for the next deployment.

Enabling non-developer users to deploy config will be the next challenge, but it is technically possible. There is also the ability to use config ignore on the horizon, great if you want to exclude all webforms from config (although I'd rather if they stayed in config and editors could simply deploy from another environment).

7. Single Sign On

All the tools you need: Ticketing system, Environment UI, Gitlab, and so on, are all accessible through a single login (with TFA support) This feels very cohesive to me, and reduces the password fatigue associated with systems like this.

8. Ahoy

I love this task runner, partly because it's so simple and accessible. You can learn a lot about how the system works by seeing a command broken down into docker compose and drush commands. Hoping to see it extendible with a personal ahoy file, I do this locally but I have to make changes to the main .ahoy.yml file which I can't push upstream. Commands like ahoy mysql-dump are proving intuitive to use and remember, so thanks team! 

9. Solid Drupal 8 distribution

The actual GovCMS upstream repo is, I think, a pretty good example of a Drupal 8 distribution. I have used it a couple of times on Platform.sh, when needing to create PoCs or projects which could be easily migrated to the GovCMS platform. This also gives me a way to train both GovCMS and best-practice Drupal development.

When it comes to working with the platform directly, I cry a little that the SaaS repo only contains the /themes and /config (etc) directories. But I accept that this is a workable solution that puts the right focus on what can be customised, especially for new vendors. There is not technical reason it has to be this way, but I see that it would make "locking" the master branch on GitLab simpler to manage.

10. Those updates

GovCMS team are pretty committed when you think about it. If a department is hosting with DPC platform in Victoria (also Lagoon) and they have any custom code (theme or otherwise), they need a vendor to support the updates. GovCMS team has a policy of supporting security updates even if the theme has a lot of code. I'm thankful on their behalf that GovCMS is no longer a sprawling Drupal multisite, as the Lagoon platform has the tools to build and rollback containers as needed.

11. Open source FTW

As much as I am a Platform.sh fanboy, Lagoon is a bit of a cracker. When Amazee.io open-sourced Lagoon, it was a bit jaw-dropping, partly due to the apparent complexity and smatterings of technical debt. They have then proceeded to making regular improvements as part of roll-outs to the DPC and GovCMS projects.

I still have to pinch myself that we have an open source Drupal hosting platform running in two major government departments in Australia. 

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Comments

  • Allowed HTML tags: <em> <strong> <cite> <blockquote cite> <ul type> <ol start type> <li> <dl> <dt> <dd> <p>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [gist:#####] where ##### is your gist number to embed the gist
    You may also include a specific file within a multi-file gist with [gist:####:my_file].

Spread the word