A part of hosting a website is ensuring that you maintain good up time. With my UX-Woman jobs board project, keeping the site up during deployments is crucial to maintaining trust with the community, and providing a good experience for our customers. In this post, I will be going over my strategy for deploying the jobs board with no down time.

Infrastructure

I am currently running my infrastructure on digital ocean, with a $12 per month 1 vcpu 2 gb ram instance. On this host, I am running an Nginx reverse proxy, and the stack for the actual webstite and backend. All services are running as a seperate frontend and backend stack, where the backend is not exposed externally outside of the docker compose.

Deployment Strategy

I do not have any CI/CD automation, instead I manually deploy the services. I begin by staging the latest versions of the depenedencies. I do this by installing the updated packages via npm install. I then zip the node_modules, and copy that over to the digital ocean host along with the package-lock.json, and the web-service-config.json in case it changed. From there I restart the service, but I also do something else.

You may be wondering why I zip the node_modules vs installing dependencies at compile time via docker. The answer is that some of these dependencies are in a private registry on my home network which is inaccessible from my digital ocean environment. So instead, I bundle the dependencies on my local network and then copy the node_modules at docker compose build time.

Blue Green Deployment

I am using the blue green deployment strategy to ensure there is no down time for the site. What this means is that I have 2 versions of the website running during deployments. Let’s say I have a live site on deployment A. I will then update deployment B’s configurations and dependencies, then start it. From there I test via the direct service ports, and when testing is complete, I update the nginx configuration to point the reverse proxy at the B deployment. Finally, once this is complete the new site is live and I can stop deployment A. On the next deployment, I repeat this process, but with the deployments in reverse so that I flip from the live B deployment to the A deployment.

Wrapping Up

So that’s basically it, this is how I have been able to maintain 100% uptime even during deployments. Although it would be ideal to have a full CI/CD pipeline, this manual process works right now. Considering this is only one site, and swerve makes creating stacks easy, the benefits of building a full pipeline is not really worth it right now.

Another nice thing about this approach is you really get to understand how automation works under the hood. This strategy is similar to what ECS does on AWS, it temporarilly runs multiple instances with your different versions, and updates the load balancer to point to the new host. Doing this manually let’s you understand each step of the deployment. This is something I learned at my first job out of school, CardWorks, where we would manually deploy our dll’s in the proper directory structure then restart the thread pool.

Anyway, hope this can help others out. As always, keep it Swizzy,

J