Your team is churning out features almost as fast as you can think of new ones. The business people are happy, and the latest version of your software is rolled out without any bugs. Your future is so bright; you gotta wear shades!
Are you using Jenkins for automation deployment? If not, it’s about time you gave it a shot. Keep reading for your quick guide to using Jenkins for your DevOps team.
What is Automation Deployment?
If you’re a certain age, you will remember using floppy disk drive [or even tape drives if you’re a true geezer] to install software on a computer. Before the internet became popular, software development teams had to physically deploy the code to the end users with magnetic media. Deployment often meant mailing disks to tens of thousands of users.
Worse yet, it was the model of simply forcing every user to buy a new version every time the software was upgraded. This was a recipe for losing customers with every version. Today patches and security updates come out so fast it would be crazy to charge customers for every version upgrade.
In most modern distribution models, the entire process is continuous. Security patches come out all the time, and users expect updates to happen mostly in the background.
Downtown has become unacceptable, and users don’t even want to hear about this stuff. They expect it all to happen in the background, by magic.
What is Jenkins?
Jenkins is a software program used for Continuous Integration, or C.I. Continuous integration is the concept and practice of bringing the entire series of steps in deployment and rolling them out as soon as possible. The whole process becomes continuous.
Instead of mailing floppy disks to customers when a new version comes out, in continuous integration, as soon as the code is confirmed into the base, it goes out. Version numbers don’t correspond to rollout events but are just the order in which the software is created.
Jenkins is like a manager who executes certain steps that are needed for the deployment process. There are typical steps that are always done, and Jenkins can tweak them.
Version Control
One of the cornerstones of the Agile revolution in software is using the concept of a distributed version control system like Git. Git allows every developer to have a complete copy of the code base. It allows branching and merging.
In Git, the developer branches off from the master branch to work on his local copy of the code. At some point, he decides that the code he is working on is good enough to send back to the group, so he makes a “commit.” The team leader can then “merge” the commit into the main branch or reget it by throwing it back to the developer.
As version control began to become popular, teams began to form patterns of behavior with each commit. Certain steps need to be done every time. Teams that ran unit tests, for instance, had to run the regression suite with each build.
In C.I., once these are identified, they can be automated. That’s the whole idea behind automation deployment. Make the robot do what the human used to do.
The Butler
Jenkins is a tropism for a distinguished “butler” or “manservant.” If you can imagine an old English guy in tuxedo tails, holding out a silver platter and saying, “Would you care for your tea, Sir?” – that’s Jenkins for automating deployment.
Jenkins prepares your breakfast, fetches your shoes, and turns on the bath while you take your morning constitutional. It’s like a master algorithm for the deployment of your software.
The main idea behind continuous integration is that it improves code quality, lessens the length of the development cycle, and reduces costs. Those main business metrics are the reason it’s done.
It accomplishes these goals by using technology. Jenkins is one of the main software packages being used in this type of DevOps type work environment. Jenkins is an open-source, totally free project used by almost every major software development team.
The Jenkins deploy automation runner can be set off by any series of events. These are usually time-based or related to steps in the commit chain. You might decide to back up a database at 3 am, or you could run tests after each commit. With Jenkins, it’s easy to have exactly what you need to be done in the order you need it.
Normally, you’ll use the Jenkins management console to orchestrate activities. You can set off scripts or run commands based on whatever criteria you desire. The most common use case is to run tests after a code commit.
Commercial Git repositories like GitHub and Bitbucket offer “webhook” services for free with their repositories. When a developer makes a commit, the service fires an HTTP request to any location you designate on the internet.
You devise a webhook from Github to run some commands in your Jenkins activity manager, like running tests. Then the results can be piped back out to a report view. Jenkins’s automated deployment makes the whole process easy to understand and control.
The “build pipeline” refers to the series of steps that Jenkins does as the commit comes in. Depending on the complexity of the project, this can be a simple or complex process.
Typically, the regression test suite will be run on cloud-based servers. The report is then fed back to Jenkins, and the Git is marked as “passed” or “tests not passed.” This gives developers an instant understanding of the nature of the commit. A lead developer can manage merges this way but only allow those branches that pass the test to enter the mainstream.
Find an IT Solution
Using Jenkins is a modern cornerstone of software development. It’s one of many integral technologies that make up the Agile DevOps revolution. With automation deployment, the developer extends himself into the organization, speeding up repetitive tasks to the lightning speed of software. If you’re interested in learning more about modern software development, contact us for the latest techniques!
