Static site CI

Continuous Integration process for the static site

A short time ago we’ve presented our site. As you might
expect, everything we do, we try to do DevOps style. That is one of shiny examples of how things can be automated
for a thing as small as our company blog.

As you already might know, we are using awesome static site generator
called Jekyll - the most popular tool from static site generators family.

Git and GitLab SaaS has been selected to
empower “Distributed Version Control System” DVCS needs for this
project.

Continuous Integration process is up and running.

We get all the above as a free service!

Follow the steps from this article to achieve similar results for your site - we will try to cover in detail what we’ve done and how.

Ideas

Making thing work DevOps style - how we see it:

Site should be placed to DVCS, and workflow working with code should be defined. Usually it implies some techniques
like code reviews, feature branches, pull/merge requests. There are many DVCS out there, but usually teams tend to use either
Git or Mercurial.

Local development must be automated to some extent, for example running local server, watching file changes & reloading/refreshing
content and many other things which are relevant to your site should be automated. Some frameworks include some useful commands to
automate things, but if not, please refer to our article on Paver and Fabric

Automated tests must be in place.

Both Production and Staging endpoints must be preserved.

Developer should be able to deploy to production/staging easily.

We will also show how to use Continuous Integration (CI) to deploy master branch to production on a change trigger.

Now, every push to non-master branch triggers the event of staging server automated deploy, and any push to master triggers deploy to prod.

Additionally, for any tag in master branch artifact is being created.
Then, we are using rsync over ssh to actually transfer files to destination server (production/staging).

Conclusion

All components pass to each other and are working perfectly. Sometimes there can be jitter with pipeline running on GitLab free shared runners, meaning sometime CI process takes longer time, but usually it does it in around 5 minutes.