Deja Consulting website

Generates the Deja Consulting website based on the Hugo static site generator. Publishing happens automatically, based on Travis CI.

Hosting is done by GitHub Pages. The site theme is a custom fork of sethmacleod's port of HTML5 UP's excellent "Dimension" theme.

Running locally

For a local preview, run:

bin/local-server.sh

The output will tell you the local URL for trying out the website. Changed resources will be updated automatically, except for changes to layouts/shortcodes, which require a restart of the process.

Automated publishing

Travis CI builds the website upon every commit to the repository.

Two branches are treated in a special way:

• release/latest: Used for publishing to the main website.

  When pushing to this branch, Travis CI commits and pushes the generated site to the main GitHub pages repository for the website. Only the latest commit will be kept over there, no history.

  This causes an immediate publish of the generated contents to the website.

• release/next: Used for publishing to the staging website, for previewing.

  Similar to release/latest, except that it will push to the staging GitHub pages repository, which is visible at the staging website.

For all other branches, Travis will simply build the website, but do no publishing.

There is no master branch. Working branches are called similar to the GitHub issue number, for example issue/4-readme/-.

The trailing dash is to allow several sub-branches for the same GitHub issue.

CV publishing

Note that pushes to this repository will also be done automatically, whenever there is a new release (or snapshot release) on the CV repository.

The CV repository not only contains the sources which build the PDFs downloadable as CV, but also many of the static texts displayed on this website. Those are written automatically to layouts/shortcodes/autogenerated. The files in this directory should not be edited manually.

Differences between main and staging

The main website and the staging website have some minor differences:

• The CNAME file, used by GitHub pages to determine the domain name under which the contents of the repository are to be published.
• The robots.txt file. The staging website will not be indexed by search engines.
• Only the main website contains a file with an arbitrary code, proving that the domain is owned by the maintainer of the site.

Trivia

Overlap with CV

Before the CV was created automatically, all website texts used to be directly on the various Markdown files of the website content pages.

However, once CV generation was automated, it became apparent that there was a substantial overlap of texts between CV and website. For avoiding redundant maintenance, it made sense to always feed those texts from the same source, so all places where the texts appear would always have the latest state, without the need to keep them in sync manually. The CV repository was the natural choice for that single source of truth, as it already provides a simple mechanism for configurable texts.

This is why most of the website texts where moved into Hugo shortcodes, so they could be easily overwritten by the CV build process, without interfering with the surrounding page code.

Once this had happened, it became apparent that it would be beneficial to keep things uniform, which meant moving other texts into the CV codebase as well, even when those texts would make no appearance outside of the website.

After this process had finished, the website source code had been transformed into a mere skeleton. Just structure with little to no text content, since the texts had moved to the CV repository.

For the future, it is questionable if it makes sense to keep a separate website repository. The CV build process could easily create the sources in the website repository by itself.

Even further, with some more adaptations, the code in the CV repository would be fit for generating the whole website HTML by itself, thereby eliminating the need for Hugo as a middleman altogether.

So it is possible that the CV and website repositories might merge in the future. However, before that happens, the website should at least support two different languages, to be a bit more evolved.