Continuous delivery of a static website

Introduction

When publishing changes to a website, the only thing that should concern us is updating the content or the layout, committing the changes and pushing.

• Speaker: David WORMS
• Duration: 30mn
• Format: talk

Presentation

Back in the days, my original workflow was to build the entire website on a local path, eg ./public and use a rsync command to push the changes on the remote HTTP server. This poses a few problems like having to wait for a few minutes before executing synchronization and the complexity to manage and set the permissions on the remote server. A recent improvement was to place the website in a Dockerfile and use an HTTP server which periodically pulls the change from the remote GIT repository. I still had to build the website locally but I could at least remove the burden of managing my remote server access permission but relying on GitHub or GitLab native authentication and editor authorization. A few months ago, after the rise of continuous delivery and the discovery of the js.org DNS service, the complete picture stuck in my mind. I could externalize the all delivery chain leaving me with what only matter. The big bonus in this solution is how anyone proposing a pulling request to improve the website will see their proposed changes automatically published once merged.

In this brief presentation, we will explore a solution to publish a website in a matter of minutes with notification in case of failure and without having to deal with any infrastructure. No GIT server to maintain, no HTTP server to monitor, no build command to wait for, no DNS to manage.

Author

Passionate about programming, data, and entrepreneurship, David Worms participated in shaping Adaltas to be a team of talented engineers to share their skills and experiences.