Sign In or Register
Not Registered Yet?

Join Now! It's FREE. Get full access and benefit from this site

Reset My password - Remind Me My username

Remember me
DevOps is an important component for software industry today. Developing and implementing a DevOps culture helps to focus IT results and to save time and money as the gap between developers and IT operations teams closes. Just as the term and culture are new, so are many of the best DevOps tools these DevOps engineers use to do their jobs efficiently and productively. To help you in your DevOps process, we have searched and created this list of DevOps tools which is mostly used by DevOps Engineers in their projects.
1. Chef

Chef is an extremely popular tool among DevOps engineers. From IT automation to configuration management, Chef relies on recipes and resources so you can manage unique configurations and feel secure knowing Chef is checking your nodes and bringing them up to date for you.
Key Features:
  • Manage nodes from a single server
  • Cross-platform management for Linux, Windows, Mac OS, and more
  • Integrates with major cloud providers
  • Premium features available
2. Jenkins

An extensible continuous integration engine, Jenkins is a top tool for DevOps engineers who want to monitor executions of repeated jobs. With Jenkins, DevOps engineers have an easier time integrating changes to projects and have access to outputs to easily notice when something goes wrong.
Key Features:
  • Permanent links
  • RSS/email/IM integration
  • After-the-fact tagging
  • JUnit/TestNG test reporting
  • Distributed builds
3. Puppet

Puppet is an open-source configuration management tool. It runs on many Unix-like systems as well as on Microsoft Windows, and includes its own declarative language to describe system configuration. DevOps engineers often rely on Puppet for IT automation. Get a handle on configuration management and software while making rapid, repeatable changes with Puppet.
Key Features:
  • Automatically enforce consistency of environments
  • Works across physical and virtual machines
  • A common tool-chain
  • Support key DevOps best practices, including continuous delivery
4. Ant

A Java library and command-line tool, Apache Ant looks “to drive processes described in build files as targets and extension points dependent upon each other.” This build automation tool is one that saves DevOps engineers a great deal of time.
Key Features:
  • Supplies a number of built-in tasks for compiling, assembling, testing, and running Java applications
  • Builds non-Java applications, such as C or C++ applications
  • Pilot any type of process which can be described in terms of targets and tasks
  • Extremely flexible and does not impose coding conventions or directory layouts to the Java projects which adopt it as a build tool
5. Apache Maven

DevOps engineers can manage a project’s build, reporting, and documentation from a central piece of information with Apache Maven. A software project management and comprehension tool, Maven has been a reliable tool for DevOps engineers.
Key Features:
  • Simple project setup follows best practices
  • Easily work with multiple projects at one time
  • Large repository of libraries and metadata that continue to grow
  • Extensible, with the ability to write plugins in Java or scripting languages
6. Logstash

For open source log processing, search, and analytics, Logstash is a popular tool among DevOps engineers. Because Logstash is licensed under Apache 2.0, you can use it in the way that best suits your needs.
Key Features:
  • Collects, parses, and stores logs for later use
  • Includes a web interface for searching and drilling into all of your logs
  • Ship logs from any source, parse them, timestamp them correctly, index them, and search them
7. Docker

An open platform for distributed applications, Docker is an application for DevOps engineers who want to “build, ship, and run any app, anywhere.” With Docker, you can quickly assemble apps from components and work collaboratively.
Key Features:
  • Assemble multi-container apps and run on any infrastructure
  • Compose an app using both proprietary containers and Docker Hub Official Repos
  • Manage all containers of an app as a single group
  • Cluster an app’s containers to optimize resources and provide high-availability
8. New Relic

With New Relic APM, DevOps engineers spend less time monitoring applications and more time on building and deploying. A popular, reliable tool, New Relic APM is a great choice for DevOps engineers.
Key Features:
  • Helps in the build, deployment, and maintenance of web software
  • Application monitoring in one place
  • Cross application and transaction tracing
  • Database and availability and error monitoring
9. Gradle

Gradle is a robust tool for automating building, testing, publishing, and deploying software packages and other projects. With the combined power and flexibility of Ant and Maven, Gradle is an open source build automation system which is perfect and very useful for DevOps engineers.
Key Features:
  • Declarative builds and build-by-convention
  • Language for dependency-based programming
  • Structure your build
  • Deep API
  • Multi-project builds
  • Ease of migration
10. Git 

Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Key Features:
  • Working offline
  • Fast to Work With
  • Repositories Are Smaller
  • Moving or Adding files
  • Ignore Certain Files
  • Branches
  • Check the Status of Your Changes
  • Stash Branches
  • Cherry Pick Changes from Branches
  • Find version that Introduced a bug using Binary Search
These are the most popular DevOps tools which are used by DevOps engineers or practitioners these days. But to make most out of these tools you need to have proper knowledge of these tools like installation process, implementation process, where to you use, how to use, troubleshooting and much more. So, if you think you need help or training for these tools or for DevOps related helps than we are here to assist you with our industry expertise professionals.
Jenkins Remote access API Example
Jenkins provides machine-consumable remote access API to its functionalities. Currently it comes in three flavors:
JSON with JSONP support
Remote access API is offered in a REST-like style. That is, there is no single entry point for all features, and instead they are available under the ".../api/" URL where "..." portion is the data that it acts on.
For example, if your Jenkins installation sits at http://ci.jruby.org/, visiting http://ci.jruby.org/api/ will show just the top-level API features available – primarily a listing of the configured jobs for this Jenkins instance.
Or if you want to access information about a particular build, e.g. http://ci.jruby.org/job/jruby-base/lastSuccessfulBuild/, then go to http://ci.jruby.org/job/jruby-base/lastSuccessfulBuild/api/ and you'll see the list of functionalities for that build.
Remote API can be used to do things like these:
Retrieve information from Jenkins for programmatic consumption.
trigger a new build
create/copy jobs
Jobs with parameters, Also see Parameterized Build.
Simple example - sending "String Parameters":
curl -X POST JENKINS_URL/job/JOB_NAME/build \
  --data token=TOKEN \
  --data-urlencode json='{"parameter": [{"name":"id", "value":"123"}, {"name":"verbosity", "value":"high"}]}'
Check Jenkins Job Status via REST API
job_status=`curl https://jenkins/view/job/other-job/lastBuild/api/json | grep "\"result\":\"SUCCESS\""`
if [ -n "$job_status" ]
    # Run your script commands here
  echo "BUILD FAILURE: Other build is unsuccessful or status could not be obtained."
  exit 1
How to restart Jenkins manually?
To restart Jenkins manually, you can use either of the following commands:
(jenkins_url)/safeRestart - Allows all running jobs to complete. New jobs will remain in the queue to run after the restart is complete.
(jenkins_url)/restart - Forces a restart without waiting for builds to complete.

Environment variables and properties defined in jenkins

Jenkins Set Environment Variables

When a Jenkins job executes, it sets some environment variables that you may use in your shell script, batch command, Ant script or Maven POM 1. The following table contains a list of all of these environment variables.

Environment Variable Description
BUILD_NUMBER The current build number, such as "153"
BUILD_ID The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss, defunct since version 1.597)
BUILD_URL  The URL where the results of this build can be found (e.g. http://buildserver/jenkins/job/MyJobName/666/)
NODE_NAME The name of the node the current build is running on. Equals 'master' for master node.
JOB_NAME Name of the project of this build. This is the name you gave your job when you first set it up. It's the third column of the Jenkins Dashboard main page.
BUILD_TAG String of jenkins-${JOB_NAME}-${BUILD_NUMBER}. Convenient to put into a resource file, a jar file, etc for easier identification.
JENKINS_URL Set to the URL of the Jenkins master that's running the build. This value is used by Jenkins CLI for example
EXECUTOR_NUMBER The unique number that identifies the current executor (among executors of the same machine) that's carrying out this build. This is the number you see in the "build executor status", except that the number starts from 0, not 1.
JAVA_HOME If your job is configured to use a specific JDK, this variable is set to the JAVA_HOME of the specified JDK. When this variable is set, PATH is also updated to have $JAVA_HOME/bin.
WORKSPACE The absolute path of the workspace.
SVN_REVISION For Subversion-based projects, this variable contains the revision number of the module. If you have more than one module specified, this won't be set. 
CVS_BRANCH For CVS-based projects, this variable contains the branch of the module. If CVS is configured to check out the trunk, this environment variable will not be set.
GIT_COMMIT  For Git-based projects, this variable contains the Git hash of the commit checked out for the build (like ce9a3c1404e8c91be604088670e93434c4253f03) (all the GIT_* variables require git plugin)     
GIT_URL For Git-based projects, this variable contains the Git url (like This email address is being protected from spambots. You need JavaScript enabled to view it.:user/repo.git or [https://github.com/user/repo.git])
GIT_BRANCH  For Git-based projects, this variable contains the Git branch that was checked out for the build (normally origin/master) 


Promoted Build Plugin Environment Variables

If you are using the Promoted Build Plugin, you will have access to the following environment variables. This allows you to access information about your Jenkins build since certain environment variables stated above (such as BUILD_TAG now refer to the Promoted Build Plugin's job.

Environment Variable Replaces Description
PROMOTED_URL BUILD_URL The URL of the original Jenkins job that is involved with the promotion. BUILD_URL now refers to the Promotion's URL
PROMOTED_JOB_NAME JOB_NAME The name of the original Jenkins job that is involved with the promotion. JOB_NAME now refers to the Promotion's job's name
PROMOTED_NUMBER BUILD_NUMBER The Build Number of the job being promoted. BUILD_NUMBER now refer's the the Promotion Number
PROMOTED_ID BUILD_ID The Build ID (ex. "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss) ) of the original Jenkins job. BUILD_ID now refer's to the Promotion's build ID.

System Properties

Name  ↓ Value   
awt.toolkit sun.awt.X11.XToolkit
com.sun.akuma.Daemon daemonized
executable-war /usr/lib/jenkins/jenkins.war
file.encoding UTF-8
file.encoding.pkg sun.io
file.separator /
java.awt.graphicsenv sun.awt.X11GraphicsEnvironment
java.awt.headless true
java.awt.printerjob sun.print.PSPrinterJob
java.class.path /usr/lib/jenkins/jenkins.war
java.class.version 52.0
java.endorsed.dirs /usr/lib/jvm/java-1.8.0-openjdk-
java.ext.dirs /usr/lib/jvm/java-1.8.0-openjdk-
java.home /usr/lib/jvm/java-1.8.0-openjdk-
java.io.tmpdir /tmp
java.library.path /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
java.runtime.name OpenJDK Runtime Environment
java.runtime.version 1.8.0_111-b15
java.specification.name Java Platform API Specification
java.specification.vendor Oracle Corporation
java.specification.version 1.8
java.vendor Oracle Corporation
java.vendor.url http://java.oracle.com/
java.vendor.url.bug http://bugreport.sun.com/bugreport/
java.version 1.8.0_111
java.vm.info mixed mode
java.vm.name OpenJDK 64-Bit Server VM
java.vm.specification.name Java Virtual Machine Specification
java.vm.specification.vendor Oracle Corporation
java.vm.specification.version 1.8
java.vm.vendor Oracle Corporation
java.vm.version 25.111-b15
JENKINS_HOME /var/lib/jenkins
jna.loaded true
jna.platform.library.path /usr/lib64:/lib64:/usr/lib:/lib:/usr/lib64/mysql
jnidispatch.path /tmp/jna--1712433994/jna4147775405825940943.tmp
mail.smtp.sendpartial true
mail.smtps.sendpartial true
os.arch amd64
os.name Linux
os.version 3.10.0-514.el7.x86_64
path.separator :
sun.arch.data.model 64
sun.boot.class.path /usr/lib/jvm/java-1.8.0-openjdk-
sun.boot.library.path /usr/lib/jvm/java-1.8.0-openjdk-
sun.cpu.endian little
sun.font.fontmanager sun.awt.X11FontManager
sun.io.unicode.encoding UnicodeLittle
sun.java.command /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --daemon --httpPort=8080 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
sun.java.launcher SUN_STANDARD
sun.jnu.encoding UTF-8
sun.management.compiler HotSpot 64-Bit Tiered Compilers
sun.os.patch.level unknown
svnkit.http.methods Digest,Basic,NTLM,Negotiate
svnkit.ssh2.persistent false
user.country US
user.dir /
user.home /var/lib/jenkins
user.language en
user.name jenkins
user.timezone America/New_York

Environment Variables

Name  ↓ Value   
_ /etc/alternatives/java
HOME /var/lib/jenkins
LOGNAME jenkins
NLSPATH /usr/dt/lib/nls/msg/%L/%N.cat
PATH /sbin:/usr/sbin:/bin:/usr/bin
SHELL /bin/bash
USER jenkins
XFILESEARCHPATH /usr/dt/app-defaults/%L/Dt


Name  ↓ Version    Enabled    Pinned   
ace-editor 1.1 true false
ant 1.4 true false
antisamy-markup-formatter 1.5 true false
bouncycastle-api 2.16.0 true false
branch-api 1.11.1 true false
build-timeout 1.18 true false
cloudbees-folder 5.16 true false
credentials 2.1.10 true false
credentials-binding 1.10 true false
display-url-api 0.5 true false
durable-task 1.12 true false
email-ext 2.53 true false
external-monitor-job 1.7 true false
git 3.0.1 true false
git-client 2.2.0 true false
git-server 1.7 true false
github 1.25.1 true false
github-api 1.84 true false
github-branch-source 1.10.1 true false
github-organization-folder 1.5 true false
gradle 1.25 true false
handlebars 1.1.1 true false
icon-shim 2.0.3 true false
jacoco 2.1.0 true false
javadoc 1.4 true false
jira 2.3 true false
jobConfigHistory 2.15 true false
jquery 1.11.2-0 true false
jquery-detached 1.2.1 true false
junit 1.19 true false
ldap 1.13 true false
mailer 1.18 true false
mapdb-api true false
matrix-auth 1.4 true false
matrix-project 1.8 true false
maven-plugin 2.14 true false
momentjs 1.1.1 true false
pam-auth 1.3 true false
pipeline-build-step 2.4 true false
pipeline-graph-analysis 1.3 true false
pipeline-input-step 2.5 true false
pipeline-milestone-step 1.3 true false
pipeline-rest-api 2.4 true false
pipeline-stage-step 2.2 true false
pipeline-stage-view 2.4 true false
plain-credentials 1.3 true false
resource-disposer 0.3 true false
scm-api 1.3 true false
script-security 1.25 true false
sonar 2.5 true false
ssh-credentials 1.12 true false
ssh-slaves 1.12 true false
structs 1.5 true false
subversion 2.7.1 true false
thinBackup 1.9 true false
timestamper 1.8.7 true false
token-macro 2.0 true false
windows-slaves 1.2 true false
workflow-aggregator 2.4 true false
workflow-api 2.8 true false
workflow-basic-steps 2.3 true false
workflow-cps 2.23 true false
workflow-cps-global-lib 2.5 true false
workflow-durable-task-step 2.7 true false
workflow-job 2.9 true false
workflow-multibranch 2.9.2 true false
workflow-scm-step 2.3 true false
workflow-step-api 2.7 true false
workflow-support 2.12 true false
ws-cleanup 0.32 true false

Useful Plugins




Page 1 of 6

Why scmGalaxy is preferred for DevOps?

What our participants say?