Jenkins overview

- [Instructor] Learning how to install, configure, and operate Jenkins will absolutely improve your value and earning potential. Jenkins is a web application that gives us the ability to do continuous integration and/or deployment. The reason why software development organizations want to do continuous integration and deployment is to save time and money, to increase the consistency in quality of deployments, to increase speed to market, which means getting the product into the customers hands quickly. Ultimately all this boils down to is automating some or all of the steps of building, deploying, and testing software. For the testing portion, I'm talking about unit testing, functional testing, acceptance testing, and maybe even load testing. Jenkins is an orchestration system that has the potential of automating all of those aspects of software delivery. Jenkins itself is a web application that was written in Java. It can be installed and run either on your own local desktop or a server. When you navigate to the Jenkins website you have the ability to create and configure jobs which can perform build and deployment automation. At a very high level those jobs have three major sections. First, the set up, where Jenkins reaches out to the version control system, like Git, to grab the codebase. The codebase might be just the product itself or it might be the product and your tests. Second, you can configure multiple build steps that will execute in sequence. Things like building the software, doing the static analysis, running unit tests, deploying the software, and finally other tests like functional tests, acceptance tests, and maybe even load testing. Then there are post build steps which typically involve collecting results from the tests and sending out notifications, whether it be e-mails, SMS, or even messages on a slack channel. To download, install, and learn more about Jenkins, you can visit the Jenkins.io website. This diagram should give you a high level idea of what continuous integration and deployment looks like. Right in the center there, we're looking at a Jenkins job, which like I mentioned in the previous slide, is comprised of a set up step, then multiple build steps, and then one or more post build steps. So Jenkins itself is a framework very similar to Robot Framework, except that Robot Framework is only responsible for automating tests, where the Jenkins framework is responsible for automating the big picture which includes your automated tests. So when this Jenkins job begins, it first reaches out to the Git Repository to grab the source code which may or may not include your tests scripts. Then on the next step it builds the code. Then it might run some automated unit tests, and if those unit tests pass it can deploy the software to the respected servers, whether it was Dev or QA or stage, or even production. Finally, you can have a step that invokes the Robot Framework pibaad command to run one or more automated functional test suites. On the top right you see a post build step where we grab the Robot Framework results and publish then within the Jenkins dashboard. While it's possible to get started with something like this one step at a time, arriving at a full continuous employment pipeline like this takes considerable time and technical skill. If your company isn't quite ready for something like this, you can just as easily use Jenkins to set up your own continuous testing mechanism that can be used by developers, QA testers, or even business people. What we see here in the middle is a representation of several different Jenkins jobs that can be triggered either by pushing a button in Jenkins, or by configuring timers. One of your Jenkins jobs could grab the Dev branch from your Git Repository and run your Robot Framework tests against the Dev environment. Another job could grab a QA branch of your automated tests and run those tests against the QA environment. Finally you can do the same thing with stage as well. You can have different jobs for different applications your company produces. You could have separate jobs for functional tests versus acceptance tests, and the list goes on and on. If you don't have the privileges and permissions to create a server for Jenkins, you can get started by installing it on your local desktop, having it talk to either an internal or a Cloud based Git Repository, and then creating different jobs with either buttons or a timer to run your various Robot Frameworks suites. So let's dig in and install it and give it a try.