Using Gitlab CI for website deployment

Written by Dominik Joe Pantůček on November 14, 2019.

Modern websites typically include both static and dynamic content. Something is pre-defined, something is generated using data gathered elsewhere and HTML templates. And when a single website has different means of producing the final pages from other content, it may be tricky to keep everything in order. Read on to see how we at Trustica use Gitlab CI to aid us with deploying Cryptoucan™ product website!

New Cryptoucan™ product website[1] is built basically from three types of data:

  1. static content – like the Privacy Policy[2],
  2. software documentation and guides – transformed from MarkDown[3] to HTML[4] using Pandoc[5], and
  3. dynamic lists of generated guides.

To make our life easier, the whole website sources are stored and versioned in git[6]. No matter if I am writing some strange conversion script or my colleague is adding a new guide, git helps is keeping track of everything. On top of git, we use private Gitlab[7] instance that gives us both project management tools like issue boards[8] and also Continuous Integration / Continuous Development[9] runner.

If you took the liberty of actually reading our Privacy Policy (that is why it is linked in the References), you might have been taken by surprise, that we really do not track anything about our users. And maybe you were surprised, that the resulting website is actually completely static. This is on purpose. The main goal is to give information. It also helps us with adding more content and developing it further.

There are three CI/CD stages in our workflow:

  1. build,
  2. test, and
  3. deploy.

The build stage – of course – builds the static website from all the resources provided. It converts MarkDown documents into HTML using pandoc, it copies all the images into proper locations and it generates the required lists. Now comes the clever part. The test stage is actually identical to the deploy stage. The only difference is that it deploys the website onto a server in our internal network and we can see if all the changes and additions are OK before we publish them.

The trick here is that the last stage can only be run manually. With this setup, the workflow is absolutely smooth. We add guides or update some images or even add some generated content and we push the changes to git. Then we wait a minute or two and we can see if everything went OK and if the result is what we wanted it to be. Publishing it on the actual website is then just a matter of single click on the Play button for the last stage in the CI/CD pipeline.

 

Thank you for reading this rather descriptive article and see you next week with some news about shipping!

References

1. https://cryptoucan.eu/

2. https://cryptoucan.eu/privacy.html

3. Wikipedia contributors. (2019, November 11). Markdown. In Wikipedia, The Free Encyclopedia. Retrieved 07:31, November 14, 2019, from https://en.wikipedia.org/w/index.php?title=Markdown&oldid=925624342

4. Wikipedia contributors. (2019, November 13). HTML. In Wikipedia, The Free Encyclopedia. Retrieved 07:31, November 14, 2019, from https://en.wikipedia.org/w/index.php?title=HTML&oldid=925951832

5. Wikipedia contributors. (2019, September 25). Pandoc. In Wikipedia, The Free Encyclopedia. Retrieved 07:32, November 14, 2019, from https://en.wikipedia.org/w/index.php?title=Pandoc&oldid=917834727

6. git –fast-version-control, available online at https://git-scm.com/

7.GitLab, available online at https://about.gitlab.com/

8.Issue Boards, available online at https://about.gitlab.com/product/issueboard/

9. Cryptoucan™ firmware CD, available online at https://trustica.cz/en/2018/11/08/cryptoucan-firmware-cd/