The 2010s elevated HTML, CSS and JavaScript to the status of the Holy Trinity of modern web development and gave us visually rich, interactive, and mobile-friendly websites.

However, it also means websites need to be built and tested before it can be released. A textbook example of a properly configured delivery process can look like this:

  1. Fetch dependencies
  2. Run Gulp/Grunt tasks, bundle assets, compile CSS, etc.
  3. Run unit tests
  4. Deploy to Stage
  5. Run integration tests
  6. Deploy to Production

Buddy lets you travel back to simple times and streamline the whole process to a single click (or push to repository) by introducing Continuous Delivery to your workflow.

Automating Node.js delivery with Buddy

Let’s create a simple pipeline that will build your application and deploy it to the server:

  1. Sign up to Buddy.Works and select the repository with your JS project
  2. Add a new pipeline and set the Trigger Mode to ‘On every push’
  3. Add Node.js action and define your tasks (the action comes with Gulp/Grunt preinstalled + you can install any missing dependencies in the ‘Packages’ tab)
  4. Add transfer action to your type of server (eg. SFTP)
  5. (Optional) You can also add a notification to keep your team updated
Pipeline example
Pipeline example

Now, make a push to the selected branch and watch Buddy automatically build and deploy your website.

Buddy uses isolated Docker containers to perform your builds. The output of the operation (eg. bundled files) is then stored in the Filesystem, from which it is deployed to the desired place.

You can switch to YAML if you prefer configuration as code over GUI.

Continuous Delivery vs Continuous Deployment

Continuous Deployment is a software engineering approach in which every change to code is rigurously tested before getting deployed to the Production server. The whole process is fully automated - from push to repository, to deployment to server.

Continuous deployment pipeline example
Continuous deployment pipeline example

In Continuous Delivery, the product is always in a deployment-ready state, but the deployment to the Production server needs to be performed manually:

Continuous delivery pipeline example
Continuous delivery pipeline example

Which process to choose depends on the company needs: in some cases, a feature must wait until it can be released live. However, if your company is not constrained by such regulations, Continuous Deployment should be the process to pursue.

Configuring Continuous Delivery pipeline

Continuous Delivery requires manual confirmation before deploying the application to Live. In Buddy you can achieve that by adding the new Wait for approval action to your workflow:

'Wait for approval' action
'Wait for approval' action

This way every time the pipeline is executed, all changes will be automatically tested, but no deployment will be made until the time is right.

Continuous delivery pipeline
Continuous delivery pipeline

Expanding the pipeline

The pipeline can be further expanded with additional actions. You can, for example:

  • Dockerize your application before the deployment
  • send a conditional notification to Slack in case the tests have failed
  • restart servers with SSH scripts
  • send HTTP POST to activate maintenance mode on the Production server or switch to atomic deployments for zero downtime
  • monitor the impact of deployments on your application

In short, Buddy lets you automate basically every type of developer task in a couple of minutes, so you can focus on delivering awesome websites with little to no deployment hassle. See you on board!