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.
I have 3 branches set up in the repository for transitioning changes through the the environments.
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.
testing - the testing branch. This branch will automatically be pushed to a testing environment.
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 visualstudio.com. 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.
The build can be triggered periodically, or when changes are pushed to the git repository. The screenshot below builds periodically and after code changes.
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.
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.
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).
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.
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.
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.