My first glance at govCMS

Salsa Digital was recently selected to work with Acquia on one of the first public govCMS platform migration from a proprietary CMS for the Civil Aviation Safety Authority (CASA).

Given the size and scope of this first and rather ambitious govCMS project, I was a little daunted jumping into it...

As a developer my first thought was “how do I build a whole site with no access to code”. I know, we should be using contrib wherever possible, but what about features, migrations, feeds or any other import / export of configuration or content? There was quite a lot of manual site builder work to be done as these options were not available, however, we still managed to implement everything required with the tools we had available to us, thanks largely to the Acquia Team.

The govCMS Profile

govCMS uses the standard Acquia setup, docroot in the repo root with govCMS setup in the profiles folder including all of it’s included contrib and custom modules. The setup for the settings.php file is pretty neat, we use something similar but generally just referencing a single file rather than referencing a wildcard.

foreach (glob(dirname(__FILE__) . '/settings.*.php') as $filename) {
 include_once $filename;
}

The module selection is fairly standard for a government site, with a clear focus on security. I really do wish they’d opted for a better admin menu, maybe Admin Menu Toolbar or my favourite of the moment, the responsive Adminimal Menu. Navigating one step at a timewith no dropdowns drives me nuts. If I was actually writing code, maybe I wouldn’t have noticed so much, but everything is done via the UI in govCMS, so that little issue was really noticeable. The funny thing about it is that on Mobile, it operates with dropdowns. The menu really does come down to personal preference and for a lot of people the amount of menu options that pop out at you in the admin menu can be a little distracting.

govcms_menu.png

govCMS Menu

This was one of the first public govCMS builds outside of Acquia and the Department of Finance and it was an honour to get selected as the govCMS vendor for this project. Being the first build, we could see from the beginning that there were still a few teething issues. The professionalism of the Acquia team is what enabled us to have a reasonably smooth build.

The process for setting up environments hadn’t been finalised, but it was resolved quite quickly. The Acquia team sorted us out with a standard professional site so we could utilise the dev, staging and prod setup that we’re used to in Acquia network. The same environments aren’t currently available within the Acquia Cloud Site Factory (ACSF) environment, which ended up being a big advantage as it gave us access to use custom code.

Ooohh, Code!

Within ACSF, there is no ability to use code, so performing site migrations and even configuration changes can be a big headache. Working within a standard Acquia professional environment allowed our team to use the Migrate module. As good as Feeds is when combined with Feeds Tamper, we didn’t have much hope of getting data from their crufty old CMS to where we needed it in Drupal without the flexibility of Migrate. Features was still out of bounds, but within our custom migrate module (read more on Sonny’s migration process) we added our Views and Feeds code to make the configuration process a little quicker and simpler.

For other configuration such as Beans and Content types, the process was quite documentation heavy. The govCMS process is 100% agile, utilising Atlassian’s Jira as the Project Management software tool. Sonny Kieu on the Salsa team created a quick markdown template, which was then used on all of the tickets requiring config. The template included all of the config : Content type definition including fields, widgets and settings, Views settings, bean settings etc. Although it was still all manual from there, the documentation provided a quick and easy way to create and verify the changes across the environments.

Better than Alpha, but still Beta

As with all newly released platforms, it’s in still in beta, but the 600+ strong Acquia team are behind it and with the speed that issues were fixed for the client, govCMS will be at v 1 very soon. The profile and the process are a good start, the module selection makes sense and the strong security focus stands the product in good stead for future releases. The hurdles are all quite easily overcome with the help of the Acquia Team. They led the process well and were always on hand to walk us through the intricacies of the system.

The project utilised the Jira integrated Atlassian Confluence product quite heavily for compiling the details of manual configuration, holding lists and descriptions of environments as well as the lengthy and detailed discussion around the complexities with the database migration.

The final step in the govCMS process was the “forklift”. Once our migration was complete, our configuration was in place and all of the content and functionality had been QA’d, the govCMS team took over to “forklift” the site into the ACSF environment. Although we can’t see inside the process, I’m assuming it’s basically lifting the db and files into place, then symlinking the theme repository. We performed our UAT remediation in ACSF and closed off the sprint.

Overall it was a pretty straightforward exercise, little code and lots of config management will take a little getting used to, but it gets the job done. Furthermore there’s good reason for it - little code means less risk of security breaches and better use of proven, mature and compliant configuration modules.

Happy Client, Happy Salsa

The Salsa team were pretty happy when the client created a final sprint named the Sprint of Awesome, calling out our team members individually for the great work they had completed. It’s always a great way to end a project, knowing that the client loved your work!