Continous Deployment with Jekyll, Jenkins, and Git

A basic example

“This is an example of Continuous Deployment with Jekyll, Jenkins, and Git”


Set up an automated deployment of your Jekyll website via Jenkins. Transition changes from development, testing, and production using 3 repository branches. The Jenkins plugins used, and doing the heavy lifting are the rbenv plugin, and Publish Over SSH.

Jenkins can continously deploy to environments using any branch. In this example, Jenkins deploys to a test environment, and production environment.

Git Repository

I have 3 branches set up in the repository for transitioning changes through the the environments.

  1. development - the development branch. I have several of these, named appropriately. Depending on what I am working on, I make seperate development branches. A development branch will not be pushed automatically, but will be a branch used during the development of a new feature, or enhancement, among the development team. In my case, I am a team of one, but I still prefer this seperation.

  2. testing - the testing branch. This branch will automatically be pushed to a testing environment.

  3. master - the “production” branch. This branch will be automatically pushed to a production environment.

Set Up Jenkins to Automatically Build and Deploy Your Site Based on Your Desired Branch

The following screeshots are only for the continous deployment of the master branch. With some minor environment and branch changes, the same concept can be used for other branches.

The testing branch may deploy to localhost or an intranet server, while the development branch will deploy to a publicy accessible website.

Source Code Managemenet

The screenshot below uses a git repository via At the time of this post, you can get a free Azure DevOps account for up to 5 users with private git repositories. This is a pretty good deal if you don’t want to pay a few dollars for the private GitHub repositories.


Build Triggers

The build can be triggered periodically, or when changes are pushed to the git repository. The screenshot below builds periodically and after code changes.


Build Environment

To build the environment, the rbenv plugin is used, which sets up the Ruby environment for us. This makes it very easy.



Since rbenv is doing most of the work, it doesn’t take much to build Jekyll.


Post-build actions

The Git Publisher is helpful for adding tags to your Git Repository. As you can see, not really used here (yet).


Without Jenkins automation, or perhaps a script, you would need to manually export the contents of the _Site folder to your web site. The Publish over SSH plugin can do that work for you.


Potential Git Commands for Transitioning Changes Through Development, Testing and Production

Begin Development on a Development Branch

Make sure you are on the development branch, or create the development branch.

   git checkout -b development

Make some changes to your Jekyll site. After you are done with the Jekyll changes, commit your code to the development branch (which you should still be on).

   git commit -a -m 'I just developed something awesome'

This may be the only “free-for-all” type branch allowed. All the other branches should have pull request reviews for transitioning code, as the testing and production environments will be built from that code. However, this example doesn’t use pull requests. You are likely the only one person maintaining your Jekyll site.

Merge your development code into the testing branch

Set up a Jenkins job to build your testing environment when changes are made to the test branch. With some modifications for the environment, you can use the screenshots from above to create a job for the testing branch. When you are ready to test the code in a testing environment, merge the development branch with your testing branch.

Make sure you are on the testing branch, or create the testing branch and merge the code.

git checkout -b testing 
git merge development 

Within a few minutes, Jenkins will build the testing environment based on the changes made to the testing branch.

Release to Production

Again, set up Jenkins job to build your production environment, based on your master branch.

git checkout master 
git merge testing 

In addition, for the testing and production branches, it is recommended to have required pull request reviews, prior to merging. You shouldn’t just merge the code without a review. An exception to that might be when you are a team of one and reviewing yourself twice over would be overkill.