Netlify CMS and Continuous Deployment for Hugo

Having experimented with this, I think Netlify’s idea of tacking a CMS onto a static site generator is tailored for situations where multiple developers, through Continuous Deployment, are providing a corporate site for which the content is being edited by non-technical users. At least it appears that way, because it takes a lot of work to develop the site and configure the CMS for anything more generic than the template provided, and an individual developer working on this as a personal project would most likely dispense with the CMS entirely and modify the files in the /content directory themselves (I’ll explain why).

Setting Up

After selecting the ‘Hugo’ option on the ‘Start with a Template’ page, we need to grant Netlify access to our GitHub account in order for it to create the repository and populate it with the source files. The file structure looks very different and far more complex than what’s created when setting up a Hugo project ourselves.

We are also redirected to the Netlify dashboard, in which sites and accounts can be managed.

The template project, hosted by Netlify, is for a Hugo-powered site with a very professional-looking theme.

What of the Content Management System? That’s accessed through the site’s portal, at https://[site-name].netlify.app/admin.

On setting this up, the CMS will send an invitation to whatever email address the GitHub account was registered with. One thing to note is that, if the name of the site was changed before you clicked the emailed invite link, you’d need to delete yourself as the user in the Netlify dashboard and create another invite. This is all under the Identity tab.

Accepting the invite and setting the password should enable access to the site’s admin dashboard.

The CMS itself looks pretty simple to use, and enables us to add, modify and delete posts, and to manage whatever images are uploaded. When a post is added, modified or removed, the changes won’t be published on the site immediately. Instead, Netlify will rebuild the entire site, and the interface under the Deploys tab will indicate a new build is in progress.

It is possible, of course, to simply add Markdown files to /content whenever we want to create a new blog post, publish them to the GitHub repository and trigger a deployment in the Netlify dashboard.

Other Options

Under ‘Deploys’ -> ‘Deploy settings’, there are quite a few Continuous Deployment settings, where we can configure the build environment and actions Netlify will perform after someone publishes changes to the GitHub repository and a deployment is triggered.

As we can see, it’s possible to specify which repository and branch Netlify will build from, which gives a development team the option of publishing changes to a different branch that can be reviewed before it’s merged with the one being published. With a bit of work, we could add a staging environment and deploy test versions of the site from a development branch in GitHub.

A ‘build hook’ enables us to use something else to trigger a deployment without having to sign into the Netlify dashboard. For example, a ‘webhook’ can be added in the repository settings on GitHub. Essentially GitHub would send a POST to a predetermined URI in order to run a build and deploy, or run a sequence of deployment-related actions.

If we’re taking a more manual approach to deploying changes, we’d publish them to the GitHub repo, and trigger a build under the ‘Deploy’ tab.

Changing the CSS, Styling and Layouts

There are many things that can’t be changed through the CMS - everything but the content is hard-coded when using a static site generator, and the CMS is designed for non-technical users to modify the content only.

CSS, styling, layouts and the content fields for the CMS are things that must be changed in the code base. The CSS is especially awkward, since there’s a CSS file for every type of element on the site, and finding specific rules involves searching for them within the /src/css/imports directory.

To change the pages of the site:

• Rename the subdirectories within /content.
• Modify the entries in /site/static/admin/config.yml for the content subdirectories.
• Change the HTML in the navigation partial view.