We have a server on which there are many projects based on WordPress and Magento CMS. As a PHP developer, I was tasked with implementing Jenkins for these projects so that publishing source code changes to the server would be faster.

Why do we need Continuous Integration?

The issue of increasing the efficiency of development and maintenance of software products for me, as a web developer, has always been and remains relevant and interesting. The processes of assembling a project and publishing it to the server are the link that can be easily automated using tools Continuous Integration (CI).

CI has been used successfully by many for a long time. Using this development method allows you to significantly reduce the time for publishing a project on the server, reducing this work to the execution of several console commands. In addition, when using CI, it is possible to quickly return to previous version project, due to the fact that Continuous Integration is inextricably linked with the version control system repository.

The principle of CI is quite simple. In my case, 3 servers were involved:

• Version control system (VCS) server where the repository is stored working version project into which the developer saves his changes.
• Continuous Integration server on which one of the CI management systems is installed.
• The server where the working version of the project is deployed.

Immediately after changing the repository in the version control system, the VCS server initiates the execution of a task on the CI server (usually using a webhook). This task builds and deploys source code from the VCS repository to the server of the working version of the project.

Deployment of source code from the SKB repository to the server of the working version of the project.

You can read more about the benefits provided by using Continuous Integration in this article.

This guide provides enough information to quickly configure the CI Jenkins system and get started with it. It also provides information on setting up and organizing the interaction of such a popular CI system, as well as an equally well-known control system Git versions. We will use GitHub as a web service for git.

Attention, task

It is necessary to install and configure Jenkins in such a way that when pushing to the GitHub repository, the changed files are updated on the server of the working version of the project. In stock:

• Debian 8.2 x64 server.
• System on local machine: Linux Mint 17.2.

The prerequisite is to have git installed on both machines. You can read about how to install it.

Solution

1. Install Jenkins

The installation will be performed on a server dedicated to CI. Enter the following commands to add the Jenkins repository to the list of system repositories:

Sudo wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add - sudo echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list

Update apt and install Jenkins:

Sudo apt-get update sudo apt-get install jenkins Restart Jenkins: /etc/init.d/jenkins restart

Now port 8080 of the CI server will be “listened” by Jenkins. This means that when you go to the address in your browser 8080 , the user will be taken to the Jenkins control panel. Of course, this access method is not very convenient, so on the CI server you can configure access to Jenkins using virtual hosts in Apache or Nginx.

Jenkins welcome window.

The next important step is to configure access rights. This is very important, especially if the server is accessible via the Internet. Without the appropriate settings, it will be open to everyone.

2. Adding an administrator

Manage Jenkins → Configure Global Security(global security setting).

1. Fill in the required information:

• Enable security- true; //enable protection;
• Jenkins'own user database— “Jenkins’ own user database”; //use Jenkins database for authorization;
• Authorization— “Matrix-based security”; //matrix distribution of access rights (distribution of rights at the project level);
• User/group to add- "admin". //grant the user “admin” access rights to the Jenkins control panel.

Adding an administrator.

2. Save the settings.

Now, when trying to log into the control panel, Jenkins will require the user to log in.

3. Create a user for GitHub

Now you need to create credentials for GitHub access to the Jenkins server.

In the Jenkins control panel, go to Manage Jenkins → Manage Users → Create User. We fill out the registration form, identical to the one that was used when registering as an administrator, click Sign Up.

After creating the user, you should give him necessary rights. To do this, let's go to Manage jenkins → Configure Global Security(global security setting).

Of all these settings we need security matrix.

First, let's add the user to this matrix. In the “User/group to add” field, enter the name of the created user and click Add. The user will appear in the matrix. Let's give it read and build rights. To do this, in the subcolumns Read And Build In the “Job” column opposite the name of the created user, set the checkboxes and click Save.

Creating a user for GitHub.

4. Installing a plugin for GitHub

Let's go to Manage Jenkins → Manage Plugins → “Available” Tab. We select three plugins to install:

• Github Authentication plugin;
• GitHub plugin;
• GitHub API Plugin.

Click on the button "Download now and install after restart" and wait for the installation to complete.

5. Setting up a server to work with Jenkins

On the production server of the project (where auto-deployment will be performed), you need to create the user “jenkins”:

Ssh-keygen

And enter the necessary information.

Also, for access, you need to add the public key to the file... /jenkins/.ssh/authorized_keys (if the file does not exist, you need to create it)

In addition, you need to create a public SSH key on GitHub for of this server. You can see how to do this.

This stage completed.

If something about ssh authentication is unclear, I recommend reading a very useful article on this topic.

6. Setting up access to the server

In order for Jenkins, when auto-deploying on a server with a working version of the project, to be able to authorize it, you need to create the necessary authentication data in the control panel. To do this, go to the Jenkins control panel Credentials → Global credentials → Add Credentials and do the following:

1. As Kind select “SSH Username with private key”;
2. Username— enter the name of the user created on the server (“jenkins”);
3. Private Key— “Enter directly”, copy the entire contents of the jenkins user’s private key file into the text field. (".../jenkins/.ssh/id_rsa");
4. Click “OK”.

Setting up access to the server.

Now you need to configure a connection to the server. To do this, go to the jenkins control panel Manage Jenkins → Manage Nodes → New Node. We perform the following actions:

1. Enter the name of the production server (for example, “target”), set “Dumb Slave”, click “OK”;
2. Enter the path to the Jenkins root directory on the production server. The root directory on the target server is usually the jenkins user directory (“.../jenkins”);
3. Enter “Labels”; for example - “target_server”. Label is the label by which the task will be associated with a specific server;
4. Host - enter the name of the host to which we will contact;
5. Credentials - select previously created authentication data;
6. Click “Save”.

After some time, the connection to the server should be successfully established. If everything went well, in Manage Jenkins → Manage Nodes you should see something like this:

Setting up a connection to the server.

If the connection is not established, click on the created connection (“target”), select “Log” in the left navigation menu and see what happened wrong.

The most common mistakes are:

First solution— change the root directory in the connection settings to the home directory of the Jenkins user.

Second solution— grant the Jenkins user rights to write and read the directory specified in the connection settings.

7. Setting up a GitHub hook

For the GitHub repository that will be used, you need to configure a webhook so that when the repository is updated, the hook sends a request to update Jenkins. For this:

• Go to the created repository on GitHub.
• “Settings” → “Webhooks & services”.
• "Add webhook".
• Enter “Payload URL” (where GitHub will go). It should have the following format

  <протокол>: //<имя пользователя для github в jenkins>: <пароль пользователя github в jenkins>@<домен>/github-webhook/

  (for example - http://github: [email protected]:8080/github-webhook/).
• "Content type" - "application/json".
• "Which events would you like to trigger this webhook?" — “Just the push event.”
• "Active" - ​​true.
• Click “Add webhook”.

The webhook has been created.

8. Create a Jenkins task

Now you need to create a task that will be executed when the repository is updated. In the Jenkins administration panel we do the following:

• Click “New Item”.
• Enter the name of the task in the “Item name” field.
• Select “Freestyle project” and click “OK”.
• “Restrict where this project can be run” - enter the tag name that was selected when adding the server (for example, “target_server”).
• “Source Code Management” - select “Git” and enter the repository address in the “Repository URL” field (for example - “ [email protected]: TestCi/Continuous-integration.git").
• In the “Credentials” field, select the previously created credentials.
• “Build Triggers” - “Build when a change is pushed to GitHub.”
• “Build” - “Execute shell” (the shell script will be executed with every push to github): sudo rsync -a —cvs-exclude —delete —omit-dir-times. /<директория проекта>sudo chown -R www-data:jenkins< директория проекта>

  The first line synchronizes the Jenkins working directory with the target project directory on the production server. The second line is to set the owner of the project files.

  — article on setting up virtual hosts in Nginx;

• digitalocean.com - article on setting up virtual hosts in Apache.

Jenkins provides continuous integration services for software development. This server system, running in a servlet container such as Apache Tomcat. It supports SCM tools including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC and can run Apache Ant and Apache Maven based projects as well as arbitrary shell scripts and command teams Windows. Jenkins's first developer is Kohsuke Kawaguchi. Released under the MIT license, Jenkins is free software.

The build can start different ways, including being triggered by a commit to source control, by scheduling through a cron-like mechanism, by building when other builds are complete, and by requesting a specific build URL.

Versions

Jenkins

Version	release date
1,656	2016-04-03
2,0	2016-04-20

Jenkins 1.x vs Jenkins 2.x

Jenkins (to this day) is a continuous integration (CI) system that allows you to automate the software development process, such as generating code for SCM commit triggers. However, the growing need for continuous delivery (CD) required Jenkins to evolve from a pure CI system to a mix of CI and CD. Additionally, the need to industrialize Jenkins jobs is growing, and the classic Jenkins 1.x Freestyle/Maven jobs have become too limited for certain needs.

With Jenkins 1.xa, a plugin called workflow-plugin was introduced to allow developers to write code to describe jobs. Jenkins 2 goes further by adding native support for Pipeline as Code. The main advantage is that pipelines, which are Groovy script files, can be more complex than freestyle standalone custom jobs and can be version controlled. Jenkins 2 also adds a new interface that makes it easy to visualize the different "stages" defined in a pipeline and follow the progress of the entire pipeline, like the one below:

For a full overview of what Jenkins 2 adds to Jenkins, see Jenkins 2 Review.

Jenkins complete Introduction in one place

1. Jenkins:

Jenkins is an open source continuous integration tool. source code, written in Java. The project was forked from Hudson after a dispute with Oracle.

In a nutshell, Jenkins is the leading open source automation server. Built with Java, it provides hundreds of plugins to support construction, testing, deployment, and automation for virtually any project.

Peculiarities: Jenkins offers the following core features out of the box, and many more can be added via plugins:

Easy to install: just run java-jar jenkins.war, deploy it in a servlet container. No additional installation, no database. Do you prefer an installer or a custom package? We have those too. Easy Configuration: Jenkins can be fully configured from its user-friendly web interface with extensive on-the-fly checks and built-in help. Rich Plugin Ecosystem: Jenkins integrates with almost any SCM or embedded tool that exists. View plugins. Extensibility: Most parts of Jenkins can be extended and changed, and new Jenkins plugins can be easily created. This allows you to customize Jenkins to suit your needs. Distributed Builds: Jenkins can distribute builds/test loads across multiple machines with different operating systems. Creating software for OS X, Linux and Windows? No problem.

Installation:

$ wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - $ sudo sh -c "echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list" $ sudo apt-get update $ sudo apt-get install jenkins to do more refer link:

Directory JENKINS_HOME Jenkins requires disk space to build and store archives. You can check this location in the Jenkins configuration screen. By default this setting is set to ~/.jenkins, but you can change it in one of the following ways: Install environment variable"JENKINS_HOME" to the new home directory before starting the servlet container. Set the system property "JENKINS_HOME" to the servlet container. Set the JNDI environment entry "JENKINS_HOME" to the new directory. For more information on how to do this for a container, see Building Specific Containers. You can change this location after you have been using Jenkins for a while. To do this, stop Jenkins completely, move the contents from the old JENKINS_HOME to the new home, set the new JENKINS_HOME and restart Jenkins. JENKINS_HOME has a fairly obvious directory structure that looks like this:

JENKINS_HOME

Config.xml (jenkins root configuration) +- *.xml (other site-wide configuration files) +- userContent (files in this directory will be served under your http://server/userContent/) +- fingerprints (stores fingerprint records ) +- plugins (stores plugins) +- workspace (working directory for the version control system) +- (sub directory for each job) +- jobs +- (sub directory for each job) +- config.xml (job configuration file ) +- latest (symbolic link to the last successful build) +- builds +- (for each build) +- build.xml (build result summary) +- log (log file) +- changelog.xml (change log)

Jenkins Build Jobs:

Creating a new build job in Jenkins is very simple: just click on the “New Job” menu item in the Jenkins toolbar. Jenkins supports several various types build jobs that are presented to you when you decide to create a new job

Freestyle Software Project

Work on creating a freestyle is a task general purpose, which provide maximum flexibility.

Maven Project "Project maven2/3" is a build job specifically tailored to Maven projects. Jenkins understands Maven pom files and project structures and can use the information obtained from the pom file to reduce the work required to set up your project.

Workflow

Organizes long-running activities that can span multiple slaves. Suitable for pipeline construction and/or organizing complex events that do not easily fit into the freestyle type of work.

Monitoring an External Job The Monitoring External Job job allows you to monitor non-interactive processes such as cron jobs.

The multi-configuration task "Multi-configuration project" (also called a "matrix project") allows you to run the same build job in many different configurations. This powerful feature can be useful for testing an application in many different environments, with different databases, or even with different build machines.

1. Building a software project (free style)

Jenkins can be used to do typical job build server such as continuous/official/nightly build, running tests or doing some repetitive batch tasks. This is called a "free style software project" in Jenkins. Project setup. Go to the Jenkins top page, select New Job, then select Build Freestyle Project. This job type consists of the following elements: An optional SCM, such as CVS or Subversion, where the source code resides. additional triggers to control when Jenkins builds. some kind of build script that performs the build (ant, maven, shell script, batch file etc.), where real work performs additional steps to collect information from the assembly, such as archiving artifacts and/or writing javadoc and test results. optional steps to notify other people/systems of the build result, such as sending an email, instant messages, tracker update, etc.

Creates projects that are not associated with the source. Sometimes it may be necessary to create a project just for demo purposes or access to an SVN/CVS repository is not available. By choosing to set up your project as "None" in the Source Code Management section, you need to:

1. Build the project at least once (it will fail), but Jenkins will create the structure jenkins/workspace/PROJECTNAME/
2. Copy the project files to jenkins/workspace/PROJECTNAME/
3. Build again and configure accordingly

Jenkins installs Environment Variables

When the Jenkins job runs, it sets some environment variables that you can use in your shell script, commands batch processing, Ant scripts or Maven POM. See List of Variables by clicking on ENVIRONMENT_VARIABLE.

Setting up automatic builds

Builds in Jenkins can be run periodically (on a schedule specified in the configuration) or when initial changes to the project have been detected, or they can be run automatically by requesting a URL:

This allows you to connect Jenkins to various settings. For getting additional information(specifically using security enabled) see Remote Access API.

Creates using source changes

You can force Jenkins to poll your version control system for changes. You can specify how often Jenkins tries out your version control system using the same syntax as crontab in Unix/Linux. However, if your polling period is shorter than what is required to poll your version control system, you may end up with multiple builds for each change. You should either configure a polling period longer than the time your version control system takes to poll, or use a post-commit trigger. You can view the polling log for each build to see how long it took to poll your system.

As an alternative, instead of polling at a fixed interval, you can use a URL trigger (described above), but with /polling instead of /build at the end of the URL. This forces Jenkins to try out SCM for changes rather than immediate creation. This prevents Jenkins from running a build without any significant changes for commits that affect modules or branches not associated with the job. When using/polling, the job must be configured to poll, but the schedule may be empty.

Creates by e-mail(sendmail)

if you have Account root of your system and you are using sendmail, I found it easiest to configure /etc/aliases and add the following entry: jenkins-foo: "| /bin/wget -o /dev/null

and then run the "newaliases" command to notify sendmail of the changes. Whenever someone sends email in "jenkins-foo@yoursystem", this will force a new build. See sendmail setup for details. Creates by email (qmail) With qmail you can write /var/qmail/alias/.qmail-jenkins like this: | /bin/wget -o /dev/null http://YOURHOST/jenkins/job/PROJECTNAME/build"

2. Create a Maven project

Jenkins provides a job type dedicated to Maven 2/3. This type of work combines Jenkins with Maven 2/3 and provides the following advantages over a more general free-style software project.

Jenkins parses Maven POMs to get most of the information it needs to do its job. As a result, the configuration size is dramatically reduced.

Jenkins listens to Maven perform and figures out what to do when he's on his own. For example, it automatically writes a JUnit report when Maven runs a test phase. Or if you run the javadoc target, Jenkins will automatically run the javadoc.

Jenkins automatically creates project dependencies between projects that declare SNAPSHOT dependencies among themselves. See below. So basically you just need to configure the SCM information and what targets you want to run and Jenkins will figure it out.

This project type can automatically provide the following features:

Archived artifacts created by the assembly

Running jobs for projects that are downstream dependent

Deploy your artifacts to a Maven repository

Breakthrough testing results by modulus

Optionally rebuild only changed modules, speeding up your builds

Automatic chaining of module dependencies

Jenkins reads your project's dependencies from your POM, and if they are also built on Jenkins, the triggers are set up so that a new build in one of those dependencies will automatically trigger a new build of your project. Jenkins understands all kinds of dependencies in POM. Namely, the parent POM

section of your project Section of your project section of your project section of your project

This process is version-aware, so you can have multiple versions/branches of your project on one Jenkins and identify dependencies correctly. Note, that dependency version ranges are not supported, see [Https://issues.jenkins-ci.org/browse/JENKINS-2787] for this reason.

This feature can be disabled upon request - see the Build whenever SNAPSHOT dependency is created configuration option

Installation:

1. go to Manage Jenkins >> configure System

1. in maven tab "Click on maven install......

You can either force Jenkins to automatically install a specific version of Maven, or you can specify the path to local installation Maven (You can configure as many versions of Maven for your build projects as you like, and use different versions of Maven for different projects. If you check the "Install automatically" checkbox, Jenkins will download and install the requested version of Maven for you and install it in the tools directory in Jenkins home directory.

How to use it

First you must configure your Maven installation (this step can be skipped if you are using DEV@cloud). This can be done by going to the system configuration screen (Manage Jenkins->Configure System). In the Maven Installation section: 1) click the Add button, 2) name it "Maven 3.0.3", and then 3) select the version from the drop-down list.

Now Jenkins will automatically install this version at any time (for example on any new machines) by downloading it from Apache and unzipping it.

Create new job Maven:

1. Clicking "New Task/New Item" on the left
2. Give it a name
3. Select "Build a Maven 2/3 project"
4. Save your work

Now you need to set up your work

Select the SCM you want to use (e.g. using git)

select maven target to call

add repository URL and credentials.

check private maven private message:

You can also define a custome path for the same.

5. Construction project

Build your project by clicking on build now and click on the left hand progress bar "Build Executor Status" to watch jenkins install Maven, check your project and build it with maven.

Script Console:

Useful for troubleshooting, diagnostics, or batch job updates. Jenkins provides a script console that gives you access to all Jenkins internals. These scripts are written in Groovy and you will find some examples of them on this page.

Moving Jenkins from one computer to another

This helped me migrate from Ubuntu 12.04 (Jenkins ver. 1.628) to Ubuntu 16.04 (Jenkins ver. 1.651.2). First I installed Jenkins from the .

Copy JENKINS_HOME (e.g. /var/lib/jenkins) from the old server to the new one. From the console on the new server:

rsync -av username@old-server-IP:/var/lib/jenkins/ /var/lib/jenkins/

You may not need it, but I had to

• Manage Jenkins and Reload Configuration from Disk.
• Disconnect and reconnect all slave devices.
• In Configure System > Jenkins Location, ensure that the Jenkins URL is correctly assigned to the new Jenkins server.

Setting up an Nginx proxy server

Jenkins is actually running on port 8080. We can set a proxy from port 80 -> 8080 so that Jenkins can be accessed through:

http:// .com

instead of standard

http:// .com:8080

Start by installing Nginx.

sudo aptitude -y install nginx

Remove default settings for Nginx

cd /etc/nginx/sites-available

sudo rm default ../sites-enabled/default

Create new file configurations

sudo touch jenkins

Copy the following code into the newly created jenkins file.

Upstream app_server ( server 127.0.0.1:8080 fail_timeout=0; ) server ( listen 80; listen [::]:80 default ipv6only=on; server_name ; location / ( proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; if (!-f $request_filename) ( proxy_pass http://app_server; break; ) ) )

Create a symbolic link between accessible sites and sites:

sudo ln -s /etc/nginx/sites-available/jenkins /etc/nginx/sites-enabled/

Restart the Nginx proxy service

sudo service nginx restart

Jenkins will now be accessible from port 80.

This article will outline the main ideas of Continuous Integration, as well as provide an example of the rapid deployment of Jenkins on a project.

Terms and Definitions

Before proceeding to the main part, it is necessary to define the terms used.

Continuous Integration (CI, Continuous Integration)- a software development practice that involves merging working copies into a common master development branch several times a day and performing frequent automated builds of the project to quickly identify potential defects and solve integration problems. [wiki]

Jenkins is an open source continuous integration project written in Java. [jenkins.io]

Automated Testing is a software verification process in which the basic functions and steps of a test, such as running, initialization, execution, analysis and output, are performed automatically using automated testing tools. [protesting]

A little about CI

Currently, Continuous Integration is one of the practices used in the Agile methodology. In such methodologies, it is successfully combined with other practices, such as unit testing, refactoring, and coding standards. But even without them, you can still benefit from continuous integration. From the definition of Continuous Integration, its most important idea follows - finding an error at an early stage is easier for development and cheaper for business. Therefore, if fairly large changes are made to the project, it is necessary to carry out testing (unit tests, automated tests).

It is worth noting that there can be several launch modes:

• tests are launched after each commit - this is ideal for unit tests and controversial for end-to-end, I will explain why below;
• tests are run once a day (most often at night). This option is not suitable for unit tests, since the application for a long time may remain inoperative, but is a fairly good option for automated functional end-to-end tests, especially when tests take a long time;
• tests are run before a release is released - one of the worst use cases, but it can also be used in conditions of limited resources, and new functionality, developed in its own branch, is tested once or several times a day.

There are quite a lot of tools for CI:

• Local ones include: GitLab CI, TeamCity, Bamboo, Jenkins, Hudson, Circle CI;
• cloud - BitBucket Pipelines, Heroku CI, Travis, Codeship, Buddy CI, AWS CodeBuild.

Jenkins

Why you should use Jenkins:

• free and reliable;
• a large number of manuals for work, which means it’s easier to learn how to work with it;
• easy to backup and deploy on another machine within 5 minutes;
• You can manage it by configuring and moving xml files.

Of the minuses I would note:

• frequent release of new versions if non-LTS is used;
• integration with various services is tied to many different plugins;
• Sometimes a task may appear that requires a non-standard approach.

Let me give you a memorable example. It is necessary to support several versions of the product that work with different versions of java, and if the project was launched with the wrong version, then the tests steadily began to fail. To do this, I had to add a plugin - Environment Injector, and also add an additional step in the assembly, which, depending on the version of the product, changed the parameters of the working environment to use a specific version of java:

In the case of the case described in the example above, on TeamCity it was enough to specify the java version when starting the run.

Separately, I note that in this case Jenkins was used exclusively to run automated tests, because they were quite long and required high level productivity.

An ideal development process can be represented as follows:

• the developer submits the code to the repository;
• on the continuous integration server, changes are combined with the main code, unit tests are performed;
• the artifacts obtained in the previous step are loaded into a separate test environment, where the application is tested by automated tests;
• Then everything is checked to get to production;
• deployment to production.

Installing Jenkins

Quite a lot and in detail has been written about installation; the best manual, of course, is from the developers - Installing Jenkins.

Backup

You can use built-in plugins, but there may be compatibility issues different versions plugins, so for this purpose we came to use bash scripts that were included in a separate assembly that was launched several times a day/week. For example, the jenkins-backup.sh script saved the current working configuration: view, job, environment settings, plugins, which were saved in a separate archive that can be transferred and used further.

Installing from a saved copy

1.You need to install java and an archiving tool, in our case unzip.

2. Unzip the previously saved file (after going to the directory with the saved archive):

unzip Jenkins.zip -d %path_To_Jenkins%

3. Go to the Jenkins directory and run Jenkins with the command

cd %path_To_Jenkins% && java -jar jenkins.war

4. Go to WEB interface on port 8080.

If you are working with a Linux machine via ssh, then after closing the connection, Jenkins will probably be stopped. In order to avoid this behavior, you can use the following technique: execute the command with the addition of the & symbol - as a result, the command will be executed in the background, and control will be returned back to command line, and in order to ensure that running tasks do not end when you disconnect from the remote system, you can use the nohup utility, which allows processes to continue running even after you log out:

nohup java -jar jenkins.war &

Adding Jenkins to Services

In order to linux systems To avoid the situation described in the previous paragraph, you can install Jenkins as a service so that Jenkins starts automatically every time after a reboot. To do this you need to create a file /etc/systemd/system/jenkins.service command:

Sudo cat /etc/systemd/system/jenkins.service sudo vi /etc/systemd/system/jenkins.service

and add content to jenkins.service:

Description=Jenkins Daemon Environment="JENKINS_HOME=%path_To_Jenkins%" ExecStart=/usr/bin/java -jar %path_To_Jenkins%/jenkins.war User=current user name WantedBy=multi-user.target

Restart the services service: sudo systemctl daemon-reload

Command to start jenkins service: sudo systemctl start jenkins.service

restart sudo systemctl restart jenkins.service

It is important to note that the jenkins.war file can be located anywhere. In order to “pick up” the current project parameters, you can use a command that will mount the Jenkins partition to a running jenkins:

sudo mount -o bind /%path_To_Jenkins%/ ~/.jenkins/

This option will only work until the system is rebooted, so you can create a symlink in the ~/ directory:

cd ~/ && sudo ln -s /%path_To_Jenkins%/ .jenkins

Adding and preparing node for work in Jenkins

This section was written taking into account the practice that the life cycle of Jenkins and node is limited, for example, 2 weeks or a month.

To add a slave node to Jenkins, you can add each machine manually, but because of this you need to constantly log into the machine and perform the same operations, and this leads to the idea that everything can be automated as much as possible.
To do this, it is enough to create several Jobs that will sequentially execute:

1. ordering machines to be added as slave nodes in Jenkins;
2. add previously ordered machines to Jenkins using rest api or Jenkins cli;
3. deploy the required environment.

All of the above actions can be performed using additional tools: ansible - for deployment and configuration required parameters and docker – both for deploying Jenkins and for installing the environment on slave nodes.

Conclusion

The main thing is that the phrase “continuous integration” on your project is not only beautiful new-fangled words, but also actions. And if you, at least minimally, follow the principles of CI, then there will be no problems life cycle There will be much less development, and the process itself will become more enjoyable. A survey with interesting statistics on the use of CI on a project –

Today (yes, right now) many different organizational equipment and gadgets are being created and produced that cannot and will not work correctly without the proper software. And then it started 🤯

Let's go in order

Software is a program or a list of programs necessary for the operation of a computer or its devices. Wow.

Every day more and more new programs, games, additions, and updates are created. Produced every day various devices and gadgets, various sound and video cards, disk drives, printers, and others. Of course, these devices will not be able to work without the appropriate software, which in turn becomes outdated and requires updating.

Programmers are given various tasks to write software, but the human factor always takes place, and when writing a program, errors may be made, which is why the software simply will not start, or will produce an error, the correction of which may take a lot of time, which in modern conditions the economy is extremely unprofitable. And the developer runs the risk of getting hit in the ass by the Team Lead.

Thank heavens - to simplify and speed up this task, in 2008 it was created Jenkins.

Jenkins the system is open source, that is, the product is available for viewing, studying and changing. By the way, it was created on the basis Java. Jenkins allows you to automate part of the software development process, without human intervention. This system is designed to ensure the process of continuous software integration. Whoa whoa.

Continuous Integration (Continuous Integration, CI) is a software development process whose purpose is to constantly connecting working copies into a common development line, and performing ongoing automated builds of the project to quickly identify possible errors and solutions to integration problems. Here is such a conveyor.

In other words, this is the creation of several draft versions (drafts) of the project, that is, copies, in the preliminary assembly of the project.

Currently, Jenkins is used in almost any modern company where there is a need for automatic deployment of applications, as well as convenient management of various types of tasks.

First, let's figure out what deployment is in general. From English" deploy"translates as" deployment". And this is a whole process of actions that make software ready to use:

• release;
• installation;
• activation;
• adaptation;
• update;
• correction errors and others.

Automatic deployment is deployment using automated solutions.

Many users will say: “Why do you need Jenkins, when there is Buildbot?. We have an answer.

The main advantages and differences of Jenkins are that an ordinary, ordinary programmer or a manager with no management experience can understand it. And he will do it in a short time.

Of course customize software It is also possible in Buildbot, but further work in it requires a specially trained person, which is not very convenient.

If any non-standard error occurs or is detected, Jenkins will fix this problem using additional plugins, without involving human help. Jenkins is free tool, which has enormous capabilities in the form of thousands of plugins that are constantly added and updated.

Plugin this is a software block that is built into the program and expands its capabilities, and since Jenkins has a lot of all kinds of plugins, the possibilities of such automatic deployment are not limited.

Jenkins is a standardized program that even a specialist with little background (experience) in IT can master in just a few hours.

It is worth noting the main advantages of Jenkins:

• operating mode in two or more environments at once;
• increased reliability of deployed software;
• reduction of errors associated with human factors;
• reduction of personnel costs. Bye – bye bye operating system and cost;
• simplification of the work process (there is no need to hire an expensive team of experienced specialists; a small group of employees without special qualifications can handle Jenkins).

Watch YouTube tutorials and be sure to give this tool a try. We are sure you will not regret it at all. But it is not exactly.

Was this article useful to you?

Please tell me why?

We are sorry that the article was not useful for you: (Please, if it is not difficult, indicate why? We will be very grateful for a detailed answer. Thank you for helping us become better!