Start a personal dev blog on your domain for free with Hashnode and grow your readership.
Get Started

Setting up a Continuous Integration and Delivery (CI/CD) Pipeline using Buddy at Hashnode

At Hashnode, we are always working hard to make your experience better and we recently fixed our deployment process entirely based on a discussion on Hashnode. This will enable us to deliver your favorite features faster than ever before.

The Problem

So, what did we fix? The need to have a human being responsible for deployments (in some cultures, these human beings are referred to as DevOps engineers). Until now, we manually SSH-ed onto the production machines, pulled the latest code and restarted our servers. Only some of us were given with access to our production and staging machines and hence, we needed to bug our backend engineers to drop whatever they were doing just so we could get our latest bug fixes and features deployed.

Continuous Deployment is very essential and shouldn't be a manual process in the modern day. We were building features left, right and center before and hence didn't really have the chance to sit down and automate the entire deployment workflow. But, hey it's 2017 and we didn't really want to put the automation off any longer. Besides, if we automate our deployment process we will have a lot more time on our hands to think of ways to make the Hashnode experience better.

The Solution

Enter CI/CD SAAS products. There are so many wonderful tools out there to automate your deployment process and we were really spoilt for options (thanks to the amazing responses we received here on Hashnode) and couldn't decide on what to pick.

We had initially settled on a product called CodeShip (who've built a fanstastic product btw), but our only concern was that our source code was pulled onto their build machines and we weren't too comfortable with that. We also thought about using Jenkins for automating our deployment process (I personally was dreading this since Jenkins is hard to set up and maintain). Moreover, it's good for companies to focus on their own business and not try to reinvent the wheel by building their own CI/CD solution. We then decided to ask the users of Hashnode what they thought about Jenkins and Codeship.

There are so many good solutions that were suggested to us, but the only problem was that either they were too expesnive or did not have an on-premise solution. We decided to go with a free on premise product called Buddy (they also have an excellent cloud product). So, how did we go about the whole automating our CI/CD pipeline with Buddy?


  1. Day 1 of the week, we sit down and decide that we need to fix our problem of CI/CD. We discuss the final workflow in detail, the goal being when developers check-in code, they should automatically see it deployed in our staging environment within a few minutes.

  2. Day 2 of the week, we decided to try out the various options available to us. We spent day 2 entirely on evaluating CodeShip. We were impressed with the workflow, but the pricing was a tad steep at $99/month. Also, we discovered the huge red flag of our code getting pulled onto their machines and they didn't have an option of BYOH (Bring Your Own Host). We decided to evaluate Jenkins the next day and go with it, but we secretly knew that it was going to be a pain. This is when we decided to reach out to all Hashnoders and see what everybody thought we should do.

  3. Day 3 of the week, we went through all the answers we had received in depth and played around with a few more products. Then, Buddy happened. Within a few minutes, we had a pipeline running on their cloud product. We immediatelty discovered that they've a free on-premise product as well and the free plan perfectly seemed to fit our small team. We booted up a DigitalOcean machine and had a test pipeline running within minutes.

  4. Day 4 of the week, all of us were super convinced and decided that we were ready to use Buddy and wanted it installed on our production infrastructure. Our production machines are from Azure and we will very quickly look at how to get your own on-premise Buddy solution working.

  5. Day 5 of the week, we had successfully automated our CI/CD pipeline. No more depenency on our backend enginners to get our code deployed and they can actually spend their time wholly on writing code (and chill out as well).

Running Buddy on Azure

Without further ado, here's how you get buddy running on your Azure (or any other cloud provider's) instance.

  1. Boot up a VM with these specs: Ubuntu 16.04, 20 GB of space and 4 GB of RAM. These are only recommended settings and we went with Ubuntu 16.04, 40 GB of space and 3 GB of RAM (we weren't going to run heavy loads anyway).

  2. The buddy on-premise product is packed nicely into a Docker container (don't be scared if you don't know what docker is, you don't need to know - for now, think of it as a packaging system like zip). So, you need to install docker and docker compose now. Let's run these commands on our newly booted VM:

      sudo apt-get update
      sudo apt-get install apt-transport-https ca-certificates
      sudo apt-key adv --keyserver hkp:// --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
      echo "deb ubuntu-xenial main" > /etc/apt/sources.list.d/docker.list
      sudo apt-get update
      sudo apt-get install docker-engine
      curl -L`uname -s`-`uname -m` > /usr/local/bin/docker-compose
      chmod +x /usr/local/bin/docker-compose
  3. Get Buddy running:

    curl -sSL | sh && sudo buddy install

  4. If your cloud provider is not Azure, then step 4 is not for you. You have successfully set up Buddy when the above command runs to completion. A url (which is your public ip) will be shown to you at the end of the installation process, which is your own installation of buddy. If you're on Azure, and your VMs are deployed inside a VPN, you need to allow inbound traffic on these ports HTTPS (443), HTTP (80) and the SSH port you picked during your installation phase. Then, run the following commands on your VM.

      buddy stop 
      buddy configure

    Now, enter the public ip of your machine, when you're prompted. Boom! Buddy is installed. Getting a production ready pipeline on Buddy is incredibly easy. So, do try it out and let us know what you think of it. Happy deployment and feel free to comment on this post if you've any questions!

Start a personal dev blog on your domain for free and grow your readership.

3.4K+ developers have started their personal blogs on Hashnode in the last one month.

Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more

Alexander Kuś's photo

Thanks a lot for featuring in your article. Development automation is certainly not a new flavor in 2017 but it's still surprising how few companies have actually introduced it to their workflow. I guess one of the reasons is people being scared of the difficulties they may have setting it up — hopefully with Buddy the process shouldn't take more than 15-30 minutes, depending on the complexity and nature of the project. Then it all brings down to a push to the repository:

Trigger on push

It'd be interesting to see an update in a couple of weeks covering how you use Buddy to automate your tasks and deployments in Hashnode development and the kind of problems you have to face. Still, outstanding job with the article — happy coding with Buddy!

Siddarthan Sarumathi Pandian's photo

Thank you, Alexander! We have had fun so far with buddy and have zero complaints. Will get back to you with a full blown review in a couple of weeks. :)

Chris Duncan's photo

Buddy is on the "I should try" list.

Link to the page:

Vishnu Bharathi's photo

Siddarthan Sp nice read. Its good to observe, how companies are using their own products to solve their problems.

Buddy seems to be interesting. Its really kind of them to give out "Buddy Go" for free. I will try out Buddy, when in need !