Sign in
Log inSign up

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

Siddarthan Sarumathi Pandian's photo
Siddarthan Sarumathi Pandian
·Jan 19, 2017

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?

Evaluation

  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://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D

  echo "deb apt.dockerproject.org/repo ubuntu-xenial main" > /etc/apt/sources.list.d/docker.list

  sudo apt-get update

  sudo apt-get install docker-engine

  curl -L github.com/docker/compose/releases/download1.8.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

  chmod +x /usr/local/bin/docker-compose

  3. Get Buddy running:

    curl -sSL get.buddy.works | 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!

5