First meet Jenkins

As there was no accumulation of relevant knowledge before, I also had no idea how to achieve it. So I had to look for Baidu, the keyword “automatic release”. Search a lot of tools and methods, but are mostly Java platform,.NET platform related information is not much. Jenkins was the most popular one. Microsoft also offered an automated deployment approach. There were other continuous integration tools that could automate the release, but Jenkins was chosen. The main reasons are as follows:

Open source code, plug-in rich and perfect, stable system active community, successful practice and online resources more rich installation and configuration of a simple web form of visual management pages

1. What is Jenkins

Jenkins is an open source software project. It is a Continuous integration tool developed based on Java for monitoring continuous repetitive work. It aims to provide an open and easy to use software platform to make continuous integration of software possible.

Continuous integration: **

Continuous integration is a software development practice in which team development members integrate their work frequently, with each member integrating at least once a day, meaning that multiple integrations may occur per day. Each integration is verified by an automated build (including compilation, release, and automated testing) to catch integration errors early.

2. What can Jenkins do

As we all know, the industrial revolution freed human hands and made people avoid a lot of repetitive work. Jenkins can help the development test operation and maintenance staff solve a lot of repetitive work. We can write some repetitive work into scripts, such as: Code submission, unit test execution, program compilation, construction, release, etc. packaged into scripts, Jenkins for us to execute regularly or on demand. In fact, many of Jenkins’ plugins do exactly that, essentially executing one or more Windows or Linux commands to fulfill our requirements.

3. A workflow for Jenkins

After a brief understanding of Jenkins, I have a general idea to complete the automatic release, as shown in the following figure, a workflow of Jenkins

The idea has been, the next is for this process, step by step simple implementation. NET Web application based on Jenkins automated deployment.

Two, Jenkins installation

Jenkins has both Windows and Linux versions. Since our project is based on.NET Freamwork for development, and Jenkins construction needs to compile.NET programs, so we choose to install the Windows version for more convenient compilation.

1. Download

The Windows installation package can be downloaded from the Jenkins official website at Jenkins. IO/Download /.

2. Install

After downloading, you can install it as prompted. (Windows fool install, note Jenkins is Java development, so need to install the corresponding JDK version first)

Configuration of 3.

After the installation, a Windows service named Jenkins will be automatically installed and started. Open the browser localhost:8080(the default Jenkins port number is 8080. If you need to change it, open the Jenkins installation directory to find jenkins.xml and change the port number. Then open the Jenkins service and restart the Jenkins service. If the following page is displayed after the configuration is complete, the installation is successful.

The whole installation process is very simple, basically is a fool according to the prompt operation, during the period did not encounter problems, basically about 10 minutes to get it done! The next section describes how to follow the above process. NET Jenkins continuous integration and automated deployment!

3. Obtain the source code from SVN

1. Install the plug-in

According to our thinking, the first thing to do is to get our source code. Because the source code management tool used by our company is SVN, the methods of SVN are mainly introduced here. According to Baidu’s instructions, we need to install a SVN plug-in :Subversion plug-in (if Jenkins selected the recommended plug-in when installing Jenkins, Jenkins will install it directly without installing it by himself).

2. Configure the project

After installing the plug-in, select a new free-style software project, give it a name, go to the project configuration, and find the source control options:



You need to configure the following options:

  • The Repository URL: for SVN paths, such as: https://127.0.0.1:9666/svn/HS.Mall/SoureCode/Trunk/Test
  • Credentials: Indicates the SVN user name and password
  • Ignore externals: Specifies whether to Ignore SVN external references.
  • Additional Credentials: This is important when your SVN repository associates other repositories with external references

Realm: Enter the ADDRESS of the SVN server

<https://127.0.0.1:9666> VisualSVN Server //Copy the code

Credentials: Indicates the SVN user name and password

For details on each of the other options, click the small? No. Look at it.

After the configuration is complete, click Save to build the project and view the result. If you can update the source code to Jenkins’ workspace, the configuration is successful!

Compile the application with MSBuild

1. Install plug-ins and the environment

.net applications can be compiled using the MSBuild tool provided by Microsoft by installing the plug-in :MSBuild. (Note :Jenkins server needs MSBuild installed, it is recommended to install VS development tool on Jenkins, you can enable VS debugging when build problems, save a lot of unnecessary trouble).

2. Global configuration

After the plug-in is installed, go to System > ConfigureTools to find the MSBuild configuration options:

  • Name: Make a Name for yourself
  • Path to MSBuild: physical Path of the msbuild. exe program

Note: msbuild. exe must be compatible with the version of freamwork that the program is using, so I ran into a big problem here. I started with an MSBuild tool and didn’t realize it would compile C#6.0 syntax. It is recommended to point directly to msbuild.exe in the Visual Studio installation directory to avoid many problems. For example, VS2017 in :Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin path.

3. Project configuration

Open the project we created earlier and go to Build options -> Add Build steps ->Build a Visual Studio Project or solution using MSBuild

  1. Name: Select the Name of the global MSBuild configuration
  2. MSBuild Build File: fill in the. Csproj File of the project we want to Build, the path of the relative work. Such as: / Test. The csproj
  3. Command Line Arguments:MSBuild parameters, such as /t:Rebuild
  • /P:Configuration=Release
  • / p: VisualStudioVersion = 14.0
  • /p:DeployOnBuild=True; PublishProfile=Test.pubxml
  • /t:Rebuild is rebuilt
  • /p:Configuration=Release Release Generation mode
  • /p:VisualStudioVersion=14.0 specifies the subtoolset (VS2015 =14.0, 2017 = 15.0)
  • /p:DeployOnBuild=True; Publish projects using the test.pubxml publishing file. The pubxml file can be configured at VS publishing time and is located in the Properties folder.

After the configuration is complete, click Build to view the console information. If the build is successful, it means that our configuration is correct!

4. Problems encountered

I thought it could be built smoothly according to a series of solutions provided by Baidu, but after dozens of consecutive failures, I realized that it was far from that simple. During this period, we mainly encountered several problems:

  • The syntax of C#6.0 could not be built due to the incorrect MSBuild version
  • Jenkins is talking about updating the repository source code to his own workspace and then doing the rest of the build work. Our program is very non-standard, which references many third-party dependency packages that do not belong to our version library and some self-developed public libraries. At that time, these third-party packages and public libraries were managed in another version library of our SVN, so many assemblies could not be found reference during construction. Regarding question 1: As mentioned above, you only need to find the corresponding version

Problem # 2: After searching a lot of sources and not finding a solution, I found a solution from source control.

Plan 1:

Borrowing ideas from Nuget, we use the Nuget server to manage some of our own public dependency libraries. The article about Nuget managing dependencies is in another blog post.

Scheme 2:

The external reference of SVN mentioned above was also at a loss at that time, so I frantically translated Jenkins’ English explanation. When translating Ignore externals of SVN plug-in, I found this solution, that is, SVN can set external reference. The Jenkins SVN plugin removes the Ignore externals option and fills in the Additional Credentials option with the SVN configuration for the dependent libraries. You can update these dependencies to the SVN workspace as well.

After the above two problems are solved, there are basically no difficult problems. This shows how important it is for our source code management to be scientific and standardized.

Dozens of build failures, a mess of references is a painful realization!

5. Publish data to the application server through Ftp

After a successful build, test.pubxml specifies the path to the published package (preferably in the workspace), and the next step, the thinking goes, is to find a way to Copy the published package to the root directory of the application server. As our application servers are all Windows operating systems, we cannot use SSH remote Copy like Linux. At that time, we can think of using Ftp to upload directly to the application server.

Publish Over FTP, FTP must be enabled on the application server.

2. Global configuration #

System Administration -> System Configuration locate the Publish over FTP configuration item

  • Name: Give a Name that will be used later in the project configuration
  • HostName:Ftp HostName (default port number 21, can be changed in advanced version)
  • Username: Ftp user name
  • Password: the Ftp Password

3. Project configuration

Open the project we built earlier and go to Post-Build artifacts > Add Post-Build Steps >Send Build Artifacts over FTP

  • Name: Select from global configuration
  • Source Files: Select your distribution path (here is the path relative to the workspace)
  • Remote directory: Which directory to place in the Remote directory (in this case, relative to the Ftp root directory)

Once the configuration is complete, click Save and build!

Sixth, concluding remarks

As mentioned above, we basically realized our requirements of automatic release. During this period, we started from 6:00 in the morning and finished it almost at noon. Of course, it was not as simple as described above. This article focuses on a basic approach to automated deployment, but there are many other solutions that can meet our needs, not just Jenkins. There are many details in this solution that are not mentioned in the article, such as: how to implement automated Nunit testing, how to regularly build… “, because I also provided a very detailed configuration document to my team members and trained them for many times. However, it was proved that the more detailed the document was, the more limited their ability of active thinking and operation. This also led to the fact that when I went to do other work, we still stayed at the level of my half-day research results for nearly a year, and the production environment was still not used. In fact, train of thought is the most important, with train of thought we can solve our problems through all kinds of ways, or suggest that we pay attention to the train of thought to solve the problem, start more, their practice, to learn more thoroughly! About the implementation and implementation of Jenkins continuous integration and automatic deployment under.net platform, you can leave a comment below the article.