Welcome to ShaneOfAllTrades! After taking a 6-year break from blogging due to other work and life priorities, I am back! Having grown into Senior QA, gaining deeper knowledge and involvement in the software release process on a daily basis, I decided to expand my blog categories to include deployments. My first blog will dive more into as a start, how I deploy this blog and will continue to build on that and on more deployment tools and processes, I hope you enjoy and learn along with me!

Why do we need Continuous Deployment?

The blog you are reading now, built with the Hexo framework, is written locally on my physical device to .MD files that are stored on a GitHub private repository – basically, my commit and push as all development requires, stages the code for sharing or deployment on GitHub.

These are a lot of steps already and our goal is to always reduce unnecessary steps if we want to be lean and to assure quality. Our objective is to limit our steps to just these, automating the remaining deployment.

For the deployment stage, I would typically ssh into my Ubuntu server, pull the changes and run build steps before copying files to the proper nginx directory. This can be risky; chances of user error are high, and it simply takes more time. This is where Buddy comes in, it has the ability to do all of the deployment in the background, simply triggered by pushing your code to GitHub.

Distilling Deployment out of CI/CD

Having spent many years establishing Continuous Deployment for projects under different teams, I found myself using the joint acronym CI/CD as many others do for anything related. It makes sense to break down the terms, so we can speak on the deployment side specifically without confusing everyone and to make it clear, this is not CI/CD, only part of it.

CI stands for Continuous Integration and is related to automated build, test, and linter stage of the software release process, all just before the actual deployment. We are not focused on wiring up unit tests or linters in this blog for a complete CI process, our focus for this blog is on the deployment side of things.

CD happens to stand for two acronyms, Continuous Delivery and Continuous Deployment. They essentially are the same thing, except Continuous Delivery requires an approval step or press of the button after the CI process is complete and Continuous Deployment is automatically deployed to your testing or production environment. Simple enough I hope, let’s move on!

What is Hexo?

Hexo is as I mentioned, a blog framework this website is built on, using GitHub flavored markdown that is powered and compiled into a public directory with Node.js. You can learn more about it at https://hexo.io

Let’s get into Buddy!

Now that you understand the problem, let’s get Buddy up and running, go to https://buddy.works to sign up!

Create your account and confirm email:

Create New Project

You are now a member of Buddy! Time to create a new project using your GitHub account ( or other git hosting provider ) that your Hexo project files are stored in. Select the GitHub tab, and it will automatically offer login to GitHub to facilitate the Buddy integration.

Authorize and observe GitHub integration has been established:

Select your organization, install and authorize your repositories

Now Select organization… wait for pop-up and select repository, select Install & Authorize as the last steps to creating your first project!

GitHub and your organization repositories are now integrated with Buddy

You now have a GitHub ( or other git hosting provider ) project with your repository linked and ready for your first pipeline:

Create your first pipeline

You might need to refresh the page to see Pipelines tab, then select the New pipeline to access the Create new pipeline page with defaults set, this includes On events as a Git push, so we can run as a Continuous Deployment. If it was set to Manually, then we would be Continuous Delivery as discussed earlier in the blog.
When done choosing, select Add pipeline button to complete initial pipeline creation step.

Congratulations, you now have a pipeline that triggers on a git push to master!

Now it’s time to add a built-in action for Hexo to build your npm modules and generate your Hexo website.
After adding a new action, filter down to the Hexo static site generator and select it:

Bash scripts generated

Observe that it autocompletes the commands and sets your shell to Bash as seen here:

Update Node.js version

If you take a look at the Node.js version, it is set at 16. You can change this to any version available, so to align with what I am developing on, I have upgraded that to 18.12.0:

Buddy Filesystem

After saving, in your Hexo Pipeline, take a peak at the Filesystem before your first run, just so you can see this is the Buddy Filesystem that happens to still be empty of your GitHub repository files:

Now it's time to run your first build!

For this first test, let’s do this manual, we can test the GitHub trigger later. Select the Run button and wait. Once complete you will find all has PASSED if everything worked as expected:

Buddy Filesystem populated with your GitHub repository compiled and ready to deploy!

Now head back to your Filesystem and observe you not only have the repository, but also the node_modules that npm install created and the public directory that hexo generate created.

Deployment time!

Now that we finally have built our project in Buddy, most files have served their purpose, except the public directory; this is what we will be deploying to the production server. Head over to your pipeline and select Actions:

From here select the add button under your previous action, scroll to your cloud platform or other options, I am going to choose a DigitalOcean Droplet:

Setup Integration where you are uploading files

• Use Pipeline Filesystem as these have been compiled and have your public directory, while the other option does not, just raw files
• Set Source path to public so you only deploy what you need
• Add your Server details for example my Integration is the DigitalOcean account while the Droplet is the actual name of the VM droplet.
• you will also need to apply a key for ssh and set the remote path you intend on deploying to. I am sure every service has different requirements here, just follow the workflow buddy shares.

Completed Continuous Deployment pipeline!

After adding keys and configuring, select the Save this action, you now have completed your Continuous Deployment pipeline!

Run the build and confirm things worked!

Last time we manually ran the build, since we have wired everything up, let’s push some code to trigger the pipeline:

With the code pushed to GitHub seconds ago, we can now see Buddy detected and is deploying the latest changes ( see Runs spinner and 30% ):

Did it work?

If you are reading this blog, it worked on my machine!