Continuous delivery enables developers to always keep their builds in a deployment-ready state. The key benefit of this approach is that it allows companies to offer new features to their users without any delays.
In this post, we’ll explain the key difference between continuous delivery and continuous deployment and walk you step-by-step through setting up continuous delivery for Node.js using Buddy – a web-based DevOps platform. Before we begin, let’s quickly take a look at the traditional delivery process for Node.js.
Traditional Delivery Process for Node.js
In its simplest form, the basic job of a web server is to open a file on the server and send the content back to the client.
PHP and ASP servers, for instance, handle file requests in the same way. When a task is sent to the computer’s file system, they wait for the file system to open and read the file. The content is then sent to the client and the server prepares to handle the next request.
However, in Node.js’s case, when the task is sent to the computer’s file system, the server prepares to handle the next request. When the file system opens, it reads the file, and content is returned to the client by the server.
In this way, Node.js effectively eliminates the need to wait and instead moves on to handle the next request. It uses memory very efficiently owing to the fact that it runs single-threaded, non-blocking, asynchronous programming. Node.js can also generate dynamic page content and create, open, read, write, delete, and close files on the web server.
A properly configured delivery process includes fetching dependencies, running Gulp/Grunt tasks, bundling assets, compiling CSS in addition to running unit tests, deployment to stage, integration tests, and deployment to production server. This is where Buddy comes in.
Buddy simplifies the traditional delivery process for Node.js by streamlining the entire process to a single push to repository by bringing continuous delivery into the picture. Before we jump into the tutorial, let’s quickly go over the key differences between continuous deployment and continuous delivery.
Continuous Deployment Vs Continuous Delivery
Continuous deployment involves thoroughly testing every change made to code before deploying it to the production server. What this means is that everything from push to repository to deployment to server is fully automated. In other words, any code commit that passes the delivery process’ testing stage is automatically released and visible to the end users.
Whereas in a continuous deliveryapproach, the build is always ready to be deployed. This is because the software code is produced in short cycles which makes it so that it can be released at any time. However, the deployment to the production server has to be performed manually.
The process you ultimately decide to go with will depend on entirely on your company’s specific needs. In certain circumstances, it takes some time before a feature can be released and made live.
But, if your company is not bound to such constraints, you should always go with the continuous deployment approach. For example, if your goal is to develop an internal app for your company, going with a continuous deployment approach will allow you to gather user feedback and better plan the next iteration.
Buddy lets you automate any type of developer task in a few minutes, so you can focus on creating great websites for your clients without any deployment issues. Next, we’ll show you how you can automate continuous delivery for Node.js using Buddy.
Automating Continuous Delivery for Node.js Using Buddy
For those unfamiliar, Buddy is a powerful, Docker-based continuous integration server that enables you to automatically build, test, and deploy applications and websites on a single push to the repository. As compared to existing continuous integration and continuous delivery platforms, Buddy has the easiest set up process and delivers an intuitive user experience.
It supports integration with GitHub, GitLab, and Bitbucket in addition to private repositories. You can automatically deploy apps to FTP/SFTP and cloud services such as AWS, Microsoft Azure, and Google Cloud. Additionally, Buddy gives you access to DevOps and website monitoring tools.
Another standout feature is its support for PHP, Node.js, Python, Java, Golang NET, and Jekyll. With Buddy, you’ll also be able to use Docker-based builds and test with auto-notifications.
Here are a few reasons why Buddy is better than your existing continuous delivery solution:
- Uses Docker containers. By using Docker containers for building your apps and websites, you’ll be able to make sure that all of your team members have the same testing environment.
- Updates servers quickly. Updating servers with Buddy happens very fast. The reason being that Buddly only deploys the modified files when you make changes instead of the whole repository each time.
- Easy to integrate into your tech stack. Buddy integrates seamlessly with several tools and platforms enabling you to easily add Buddy to your existing tech stack.
Now that we have a better understanding of Buddy’s capabilities, let’s dive right into the tutorial.
Step #1: Create a New Delivery Pipeline
Here’s how you can create a simple pipeline for building your application and deploying it to the server:
- Next, add a new pipeline and set the Trigger Mode option to On every push.
- Add Node.js action and define your tasks (the action comes with Gulp/Grunt preinstalled plus you’ll be able to install any missing dependencies by going to the Packages tab).
- Add a transfer action to the type of server you’re running (for example SFTP).
- Optionally, you’ll also be able to add a notification which keeps your team members updated.
Now, you need to make a push to the selected branch. You’ll notice that Buddy will automatically build and deploy your site.
Buddy leverages isolated Docker containers to perform these builds. The output of the operation (e.g. bundled files) will be saved in the filesystem and from there it is deployed to the defined place. If you want to use code instead of GUI as configuration, you can choose to switch to YAML.
Step #2: Configure the Continuous Delivery Pipeline
As we mentioned above, continuous delivery needs manual confirmation before the application can be deployed to the production server. With Buddy, the simplest way to achieve this is by adding the new Wait for approval action to your workflow.
As a result whenever the pipeline is executed, all of the changes made will be automatically tested though the deployment. However, they will not be deployed until they’re manually approved.
You can further expand the pipeline with additional actions that are built into and supported by Buddy. These include:
- Dockerize the application before you deploy it so that the working environment remains consistent across the entire workflow.
- Sending a conditional notification to Slack if the tests fail for easy, real-time updates.
- Restarting servers with SSH scripts after the deployment.
- Sending HTTP POST for activating production server’s maintenance mode. This is especially useful if you’re updating a service on a live server.
- Monitoring the effects of deployment (such as the impact of recent releases on app speed and efficiency) on your application.
Continuous delivery lets developers build and deploy apps that are always in a deployment-ready state. With Buddy, you’ll be able to take the heavy lifting out of deployment by automating developer tasks in a matter of minutes.
Between continuous delivery and continuous deployment, which approach do you favor and why? Let us know by commenting below.