Building and deploying modern web applications involves multiple steps - from installing dependencies and compiling assets to running tests and migrating databases. Build pipelines automate this process, making it more robust, repeatable and efficient. In this guide, we'll explore how to manage and optimize reliable build pipelines using DeployHQ.
What You'll Need
- A web application in a Git, SVN, or Mercurial repository
- A DeployHQ account (starts at $9/month, with a 10-day free trial)
- A server or hosting platform for deployment
What is a Build Pipeline?
A build pipeline is a series of automated steps that transform your source code into a deployable artifact. Think of it like a assembly line in a factory:
- Raw materials (your source code) enter the pipeline
- Each station (build step) performs a specific task
- The final product (deployable application) emerges at the end
Why Use Build Pipelines?
Build pipelines offer several key advantages:
- Reliability: Eliminate manual steps and reduce human error
- Repeatability: Ensure builds are performed the same way every time
- Efficiency: Speed up your deployments through continuous deployments
- Observability: Monitor the entire build process from a central dashboard
Setting Up Your First Build Pipeline in DeployHQ
Let's walk through setting up a build pipeline for a typical Node.js application. If you're using a different language or framework, the steps will be similar, but the commands will differ.
Step 1: Create a New Project
For this guide we assume you already have a project in DeployHQ. If not, you can create a new project by following the steps in our guide on how to setup your first deployment with DeployHQ.
Step 2: Configure a basic Build Pipeline
- Navigate to "Build Pipeline" in your project's sidebar
- Click "New Command"
- Set up your first build command:
Because we assume a simple Node.js application, we'll start with a simple build command that simply installs the dependencies with npm install and then runs npm run build to transform the source code into a deployable artifact.
Using variables to customize your Build Pipeline
DeployHQ also provides you with a templating system that you can use to inject variables into your commands. For example, you might want to use a different build command for your development and production environments.
Let's say you want to run npm run build for your development environment and npm run build:prod for your production environment. Since our build pipeline is simply bash, we can use the %environment% variable to conditionally run the correct command.
npm install
if [ "%environment%" = "production" ]; then
npm run build:prod
else
npm run build
fi
DeployHQ gives you a lot of variables to use in your build pipeline. Here's a list of all the variables you can use:
| Variable | Description |
| --------------- | ------------------------------------------------------------------------- |
| %startrev% | Start revision ref |
| %endrev% | End revision ref |
| %startrevmsg% | Start revision commit message (available on deployment finish or failure) |
| %endrevmsg% | End revision commit message (available on deployment finish or failure) |
| %tag% | Tag related to end revision (if present) |
| %branch% | The branch of the deployment |
| %count% | This number of deployments in the project |
| %servers% | Names of the servers in this deployment |
| %deployer% | User who started the deployment (if manually deployed) |
| %commitrange% | The start and end commit, separated with a hyphen |
| %project% | The name of this project in deploy |
| %projecturl% | The address of this project in DeployHQ |
| %projectperma% | The permalink of this project in DeployHQ |
| %deploymenturl% | The address of this deployment in DeployHQ |
| %status% | The current status of this deployment |
These variables refer to a specific server or server group:
| Variable | Description |
| ------------- | ------------------------------------------------- |
| %environment% | Server environment (development, production etc.) |
| %path% | Server only. Base server path we're deploying to |
This gives you a lot of flexibility to customize your build pipeline to your needs, go wild!
Hooking into the deployment lifecycle
Sometimes you want to hook into the deployment lifecycle to run SSH commands on your server. For example, just after connecting to your server you might want to run commands to prepare the server for deployment, or after the deployment has finished you might want to run some cleanup commands.
DeployHQ allows you to hook into the following lifecycle events: Before anything is changed during a deployment, after files have been uploaded but not released, and directly after the release has been deployed to the server. Let's go through one example each of how you can use these hooks.
Before Changes
Before Changes is triggered just after the build pipeline has finished, but before any files have been uploaded to the server and you can even decide if you want it to run on every deployment or only on the first deployment.
One of the best use cases for this is to run some server bootstrapping commands to prepare the server for deployment. When you have a fresh server, you usually want to first update your dependencies, install a firewall, setup a reverse proxy, etc. This can easily be done here:
An example command could be:
sudo apt-get update -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 22/tcp
sudo ufw enable
This will ensure that only the ports you need are open and that all other traffic is blocked. Select the "Before Changes" hook and add your commands. Then make sure to only execute this on the first deployment to the server and select an appropriate timeout.
Before Release Link
Before Release Link commands are executed after files have been uploaded/removed, but before the new release has been made active. This works only for zero-downtime deployments and is awesome for last minute smoke testing. For example, you could use this as an opportunity to make some final checks if all files are present and correct. It's always possible that something went wrong during the build pipeline and you want to avoid deploying a broken release.
If you have a few files that are critical to your deployment, you can use this hook to check if they are present. Here's an example:
#!/bin/bash
DIST_DIR="./dist"
FILES=("index.html" "favicon.svg" "index.css")
for f in "${FILES[@]}"; do [[ -f "$DIST_DIR/$f" ]] || { echo "Missing $f"; exit 1; }; done
echo "All files are present."
You can of course improve this by adding more relevant checks, but you get the idea. Variables are available in the Before Release Link hook as well, so you can easily customize the commands to your needs. You would probably not want to use a hardcoded DIST_DIR in this case, but instead use the %path% variable which refers to the path of the server you're deploying to!
After Changes
After Changes commands are executed just after the new release has been deployed to the server. That means that all files are present and ready to rock. If you have a reverse proxy setup, this is probably the best place to update the configuration so that it points to the new release. You could also use this hook to send yourself notifications that the deployment has finished.
If you have a Linux server with mailutils installed, you could send yourself a notification email like this:
echo "Deployment finished" | mail -s "Deployment commit %endrevmsg% on %environment% finished" your@email.com
The possibilities are endless!
What does it cost?
Build pipelines are included with all DeployHQ plans! The number of build minutes varies by plan. Here's a breakdown of available build minutes per month:
| Plan | Price | Build Minutes/Month |
| ---------- | ----- | ------------------- |
| Free | $0 | 30 |
| Solo | $9 | 200 |
| Pro | $19 | 800 |
| Business | $39 | 2000 |
| Enterprise | $99 | 4000 |
For perspective, if your typical deployment takes around 5 minutes, you could run it 160 times on the Pro plan before hitting the limit!
You can see a detailed breakdown of the different plans and features here.
FAQ
Got questions? We've got answers!
What is the difference between a build pipeline and a build server?
A build pipeline is a defined sequence of automated steps that transform source code into a deployable artifact, while a build server is the actual machine or environment that executes these steps. Think of the build pipeline as the recipe, and the build server as the kitchen where the recipe is prepared.
How does DeployHQ's build pipeline compare to other CI/CD tools?
DeployHQ's build pipeline is designed to be simple and easy to use, with a focus on providing a great developer experience, without needing to learn a new tool.
How does it help me in reducing deployment times?
Build pipelines remove the need to manually run commands, which can take a lot of time, especially if you have a complex deployment process.
Conclusion
Build pipelines are a powerful tool that can help you streamline your deployment workflow, reduce errors, and speed up your deployments. DeployHQ's build pipeline is designed to be simple but powerful, with a focus on providing a great developer experience, without needing to learn a new tool.
Ready to make deployments faster and easier? Start your free trial with DeployHQ today!
