Maven / Jenkins Interview questions
Jenkins is an open-source free automation tool used to build and test software projects. The tool makes it painless for developers to integrate changes to the project. Jenkins' primary focus is to keep track of the version control system and initiate and monitor a build system if there are any changes. It keeps an eye on the entire process and provides reports and notifications to alert.
- Use Jenkins to detect defects in the software development lifecycle and automate the testing of builds.
- To continuously monitor the code in real-time and integrate changes into the build.
- Jenkins is a great fit for building a CI/CD pipeline because of its plugin-capabilities, and simple-to-use nature.
- free and open-source automation tool,
- Jenkins provides a vast number of plugins,
- Easier to set up on various operating systems,
- Provides pipeline support,
- Fast release cycles ,
- Easier upgrades.
The Jenkins Web application ARchive (WAR) file can be started from the command line like this:
- Download the latest stable Jenkins WAR file to an appropriate directory on your machine.
- Open up a terminal/command prompt window to the download directory.
- Run the command java -jar jenkins.war.
- Browse to http://localhost:8080 and wait until the Unlock Jenkins page appears.
- Continue on with the Post-installation setup wizard below.
- Version Control systems like GIT, SVN.
- And build tools like Apache Maven, and Gradle.
- Maven plugin
- Amazon EC2
- HTML publisher
- JUnit Plugin
- JIRA plugin
- Green Balls
- Mailer Plugin
- Slack Notification plugin
- Docker plugin
- Pipeline plugin
Yes.
Continuous Integration is a software development process where the code is continuously tested after a commit, to ensure there are no defects/bugs.
In large teams, many developers work on the same code base. Thus, any multiple commits can cause a bug. With continuous integration, bugs can be identified early and fixed before pushing changes to production. Any new code is integrated into one executable form, termed a build. If the build is green (i.e. all ok, no bugs), then the executable artifact can be deployed. If not, the bug needs to be fixed, and the new build is tested again.
Continuous Delivery (CD) is the process of building, testing, and delivering improvements to the software code. This is still a manual process and deployment happens by clicking a button.
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.
A continuous integration and continuous deployment (CI/CD) pipeline is a series of steps that must be performed in order to deliver a new version of software. CI/CD pipeline is a process that drives software development through a path of building, testing, and deploying code.
By automating the process, minimizes human error and maintains a consistent process for how software is released. CI/CD is the backbone of a DevOps methodology, bringing developers and IT operations teams together to deploy software.
Jenkins Pipeline (or simply "Pipeline") is a suite of plugins that supports implementing and integrating continuous delivery pipelines into Jenkins. A continuous delivery pipeline is an automated expression of your process for getting software from version control right through to your users and customers.
A Jenkins Pipeline is a collection of jobs or events that brings the software from version control into the hands of the end-users by using automation tools. It is used to incorporate continuous delivery in our software development workflow.
A Jenkinsfile is a text file that contains the definition of a Jenkins Pipeline and is checked into source control. Consider the following Pipeline which implements a basic three-stage continuous delivery pipeline.
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building..'
}
}
stage('Test') {
steps {
echo 'Testing..'
}
}
stage('Deploy') {
steps {
echo 'Deploying....'
}
}
}
}
There are two types of syntax using which we can define a Jenkinsfile:
- Declarative Pipeline syntax, is a new feature that used code for the pipeline. It provides a limited pre-defined structure. Thereby, it offers an easy & simple continuous delivery pipeline. Moreover, it uses a pipeline block.
- Scripted Pipeline syntax, is the old traditional way to write the Jenkinsfile on Jenkins web UI. Moreover, it strictly follows the groovy syntax and helps to develop a complex pipeline as code.
A Jenkins project involves steps and post-build actions and is a repeatable build job.
- TeamCity,
- Bamboo,
- Perforce,
- Circle CI,
- Go,
- ThoughtWorks,
- Integrity,
- and Travis CI.
Hudson was the earlier name and version of the current Jenkins. The project got renamed from Hudson to Jenkins.
Blue Ocean is a new user experience for Jenkins based on a personalizable, modern design that allows users to graphically create, visualize and diagnose Continuous Delivery (CD) Pipelines.
A Pipeline is a user-defined model of a CD pipeline. A Pipeline's code defines your entire build process, which typically includes stages for building an application, testing it, and then delivering it. Also, a pipeline block is a key part of the Declarative Pipeline syntax.
A node is a machine that is part of the Jenkins environment and is capable of executing a Pipeline. Also, a node block is a key part of Scripted Pipeline syntax.
A stage block defines a conceptually distinct subset of tasks performed through the entire Pipeline (e.g. "Build", "Test" and "Deploy" stages), which is used by many plugins to visualize or present Jenkins Pipeline status/progress.
A step tells Jenkins what to do at a particular point in time (or "step" in the process). For example, to execute the shell command make use of the sh step: sh 'make'. When a plugin extends the Pipeline DSL, that typically means the plugin has implemented a new step.
sh is a Pipeline step (provided by the Pipeline: Nodes and Processes plugin) that executes the given shell command.
junit is another Pipeline step (provided by the JUnit plugin) for aggregating test reports.
Code: Pipelines are implemented in code and typically checked into source control, giving teams the ability to edit, review, and iterate upon their delivery pipeline.
Durable: Pipelines can survive both planned and unplanned restarts of the Jenkins controller.
Pausable: Pipelines can optionally stop and wait for human input or approval before continuing the Pipeline run.
Versatile: Pipelines support complex real-world CD requirements, including the ability to fork/join, loop, and perform work in parallel.
Extensible: The Pipeline plugin supports custom extensions to its DSL and multiple options for integration with other plugins.
You configure a freestyle job in Jenkins using the GUI by adding steps to the build. Freestyle jobs give you a lot of flexibility. But, you will struggle to configure complex continuous delivery scenarios.
Pipeline jobs allow you to create a set of instructions using code. You can also easily visualize different stages in one place. Most importantly, you can keep all the code stored in a code repository. This will, in turn, allow you to version, audit, and keep track of changes. Pipeline jobs are created using a Jenkinsfile. And Jenkins files use Apache Groovy as the scripting language.
Jenkins polls for changes in repositories regularly. Once the changes are defined, Jenkins detects them and uses them to prepare a new build.
After that, Jenkins will transverse through various stages in its usual pipeline. As one stage completes, the process will move further on to the next stage.
If a stage fails, the Jenkins build will abort, and email the team using it. When completed successfully, the code implements itself in the proper server so that testing begins.
After the successful testing phase, Jenkins shares the results with the team using it.
With the help of the Git plugin Jenkins can easily pull source code from any Git repository that the Jenkins build node can access.
The GitHub plugin extends upon that integration further by providing improved bi-directional integration with GitHub. Allowing you to set up a Service Hook that will hit your Jenkins instance every time a change is pushed to GitHub.
Using the GitHub Authentication plugin it is possible to use GitHub's own authentication scheme for implementing authentication in your Jenkins instance.
