That\u2019s it, Jenkins would initialize itself and start running, that\u2019s all as far as \u2018installation\u2019 goes. If you are wondering, your right Jenkins does not need to be \u2018installed\u2019 here, it runs as an executable. To close the Jenkins server, press \u2018CTRL+C\u2019 on the command prompt running Jenkins and the server will close. To restart run the same command for the WAR file as before<\/p>\n

Local server<\/h3>\n

Jenkins deploys a local server which is accessed through \u2018localhost:8080\u2019. A local host \u2018server\u2019 is used to \u2018serve\u2019 web pages \/ an application when requested by a client, pretty much the same way as web server does. The only difference for the client being the way we access it. A web server will require to enter a \u2018URL\u2019 which translates to an IP for a server machine. For our local host, there is no IP needed and it\u2019s just \u2018localhost\u2019, and 8080 being the port for accessing.<\/p>\n

Back in the day installing a local host server was not a behind the scene process and used to take a while, with layers of abstraction and advancement in development environments, this is now something that gets done behind the scene without the user knowing what all this entails.<\/p>\n

Initial Setup<\/h3>\n

From here on, things are quite straight forward. One first creates an admin user which first requires entering a secure password to access the console. To obtain the password, follow the instructions on the page (In this case, copy the password from the given file):<\/p>\n<\/div><\/span>

Jenkins 2.0 installs quite a few plugins as part of the default installation. They are very helpful, like some highlighted below.<\/p>\n<\/div><\/span>

Jenkins uses XML files for configuration. By default these files are placed at C:\\Users\\<logged in user>\\.jenkins\\ and can be viewed (and edited) to see and update Jenkins configurations.<\/p>\n

Basic Security<\/h3>\n

Jenkins deployed on a local \u2018server\u2019 means the application can be accessed anywhere on the network, which leads to the need for \u2018security\u2019.<\/p>\n

You can have a lot of users for logging in to Jenkins with different privileges (and even access without logging in). Once the plugins are installed, the first Admin User creation dialog appears. Pretty straight forward.<\/p>\n<\/div><\/span>

That\u2019s not all for security. Jenkins has a Global security configuration setting also. Here are a few recommended settings to do here:<\/p>\n<\/div><\/span>

Read only access<\/h3>\n

For teams triggering automated tests through Jenkins this is a very powerful feature. You would want a wide access to the reports from your automated runs, which gets a lot easier with this feature. If checked as shown below, anyone on the network can access the localhost server and \u2018view\u2019 all jobs and test results, which in my opinion is the way it should be.<\/p>\n<\/div><\/span>

If you would like to have intermediate user accounts (between the admin and read only users), you can add \/ manage user accounts here:<\/p>\n<\/div><\/span>

Docker friendly<\/h3>\n

Before I end this, I must mention Jenkins does run on docker too. That means you can have multiple Jenkins versions running. Or you can have one version but multiple backups of it which takes your environment management to a whole new level.<\/p>\n

 <\/p>\n

We talked about pre-requisites of Jenkins, ways to install and run it, using the command prompt, plugins installation and default security. This guide might not server well as a stand-alone piece, however would be great reference material while going through the process.<\/p>\n<\/div>

<\/div><\/div><\/div><\/div><\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":3,"featured_media":13774,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[45],"tags":[],"yoast_head":"\n