.NET Continuous Integration and Automated Deployment

Https://www.cnblogs.com/hunternet/p/9590287.html

I believe that every programmer has experienced the pain of late-night overtime online! And as an overtime on-line as the norm of the farm, it is deeply painful. Because of the complexity of the system business, the system is large, the design to the cooperation between multiple systems, and the core system is the use of Distributed system architecture, due to the unreasonable division of the system, and so on, each time the release will be designed to publish multiple systems, a small version of 35, A large version of more than 10 or even dozens of systems released at the same time! And we do not have the corresponding infrastructure support, the distribution is the most traditional way, the developer will release the package to the OPS staff, from which each release package is covered to a production environment. So it takes more than 2-3 hours to launch a single release. This method is not only time-consuming, but also due to the fact that manual operation often leads to some loss and fall. And our test was also the use of pure manual testing, the release after the completion of a round of regression testing will take 3-4 hours (then mainly manual testing). Continuous integration, automated testing and operations have been advocated, but they have been slow to move to the ground. Finally, after a night of overtime to four o'clock in the morning, I can't stand it any longer. Home after lying in bed sleepless, thought this automated release can have how difficult, they can't do, Lao Tze himself, so 6 point climbed up to the company, formally began my continuous integration, automated deployment of research and promotion of the road.

First, a new knowledge of Jenkins

Since there is no accumulation of relevant knowledge, it is also confused to how to achieve it. So you can only find the mother, the key word "automated release." Search for many tools and methods, but are mostly in the Java platform, the. NET platform is not a lot of relevant information. There is more to Jenkins, and Microsoft offers a set of automated deployments, and there are other continuous integration tools to automate publishing, but Jenkins is the ultimate choice. There are several main reasons for this:

Code open source, rich and complete plug-ins, System stability

Active community, successful practice and rich online resources
Simple installation Configuration
Web-style Visual Management page

What is Jenkins?

Jenkins is an open source software project, a continuous integration tool based on Java development, that monitors ongoing duplication and is designed to provide an open and easy-to-use software platform that makes continuous software integration possible.

Continuous Integration:

Continuous integration is a software development practice in which team development members often integrate their work, with each member being integrated at least once a day, which means that multiple integrations may occur on a daily basis. Each integration is validated through automated builds, including compilation, release, and automated testing, to identify integration errors early.

What can 2.Jenkins do?

As we all know, the industrial revolution liberated the human hands, so that people avoid a lot of repetitive work, and Jenkins can help develop Test OPS to solve a lot of repetitive work, we can write some repetitive work, such as: Code submission, Execution Unit test, program compilation, Build, The release, etc., is packaged as a script that is executed periodically or on demand by Jenkins. The fact that many of Jenkins's plugins are true is simply the execution of one or more Windows or Linux commands to fulfill our needs.

A workflow for 3.Jenkins

After a simple understanding of Jenkins, there is a general idea of completing the automated release, such as a workflow for Jenkins

Image

The idea is already there, and the next step is to implement the. NET Web application's automated deployment based on Jenkins for this process.

Second, Jenkins installation

Jenkins has a version of Windows and Linux, because our projects are developed based on. NET Freamwork, and the Jenkins build needs to compile. NET programs for easier compilation, so choose to install the Windows version.

1. Download

You can download the Windows installation package from the Jenkins official website https://jenkins.io/download/.

2. Installation

After the download is complete, you can follow the prompts to install it. (under Windows Fool installation, note that Jenkins is a Java developer, so you need to install the corresponding JDK version first)

3. Configuration

After the installation is complete, a Windows service is automatically installed and started, named Jenkins, which opens the browser localhost:8080 (Jenkins default port number is 8080, If you need to modify the can open the Jenkins installation directory to find Jenkins.xml modify the port, and then open the service restart the Jenkins service, then follow the instructions to configure it! After the configuration is complete, see the following interface for successful installation!

Image

The whole installation process is very simple, basically it is a fool-like operation according to the prompts, during the period did not encounter problems, basically 10 minutes or so to get it! Next, we will introduce how to implement continuous integration and automated deployment of Jenkins under .NET according to the above process!

Third, get the source code through SVN

1. Installing plugins
According to our thinking, the first thing to do is to get our source code. Since the source control tools used by our company are mainly SVN, this is the main way to introduce SVN's approach. According to the degree of Niang guidance, we need to install an SVN plugin: Subversion plug-in (if: Install Jenkins when the installation recommended plug-in, then Jenkins will directly install the plug-in, no need to install themselves).

2. Project configuration

After installing the plugin, select Create a free-style software project, name it and go to the project configuration and find the source control option.

Image

There are several options that need to be configured:

Repository URL: The path of the SVN to get, such as: Https://127.0.0.1:9666/svn/HS.Mall/SoureCode/Trunk/Test

Credentials: Configure SVN username and password

Ignore Externals: Whether to ignore SVN external references (this is very important, will be used later, about the SVN external reference, can self-Baidu)

Additional Credentials: When your SVN repository is associated with an external reference other repository it's important.

Realm: Fill in the address of the SVN server

https://127.0.0.1:9666 visualsvn Server//(Note this format)

Credentials: Fill in SVN username and password information

Some other options are available directly by default, and detailed descriptions of each item can be clicked on the back of the small? See the number.

After the configuration is complete, click Save to build the project to see the results. If the source code can be updated to the work space of Jenkins, the configuration is successful!

Fourth. compiling an application through MSBuild

1. Installing plugins and environments
Compile. NET application through the MSBuild tool provided by Microsoft, install the plugin first: MSBuild. (Note: The Jenkins server needs to install MSBuild, and it is recommended that you install the VS development tool on Jenkins to turn on vs debugging when the problem is being built, eliminating a lot of unnecessary hassle).

2. Global configuration

After the plug-in is installed, go to System Management-Global tool configuration (Configuretools) to find MSBuild configuration options.

Image

Name: Make a name for yourself

The physical path to the path to MSBuild:MSBuild.exe program
Note: Here MSBuild.exe must correspond to the Freamwork version used by the program, here I met a big pit, at the beginning casually find an MSBuild tool, did not expect to compile c#6.0 grammar. It is recommended to point directly to the MSBuild.exe in the Visual Studio installation directory to avoid many problems. such as VS2017 in: Program Files (x86) \microsoft Visual Studio\2017\enterprise\msbuild\15.0\bin Path.

3. Project configuration

Open the project we created earlier, find build options, add build step->build a Visual Studio project or solution using MSBuild

Image

Name: Select the names of the global MSBuild configurations

MSBuild build file: Fill in the path to the relative work of our project to build. csproj files. such as:/test.csproj

Command line Arguments:msbuild parameters such as:/t:rebuild/p:configuration=release/p:visualstudioversion=14.0/p:deployonbuild =true; Publishprofile=test.pubxml

/t:rebuild rebuild

/p:configuration=release Release Generation Mode

/P:VISUALSTUDIOVERSION=14.0 Specifies the set of sub-toolsets (VS2015 is 14.0,2017 15.0) and does not set an error
/p:deployonbuild=true; Publishprofile=test.pubxml publish the project using the Test.pubxml Publish file. pubxml files can be configured at vs release, located in the Properties folder.

Once the configuration is complete, click Build to view the console information, if it can be built successfully, then we have the correct configuration!

4. Problems encountered

Originally thought according to degree Niang's a series of solutions can be very smooth construction, but in successive failure dozens of times, only then understand far less simple. Several issues were encountered during the period:

The MSBuild version does not cause the syntax to build c#6.0

Jenkins is talking about the repository source code being updated into its own workspace, and then performing the subsequent build work. Our program is very irregular, which refers to many third-party dependencies that are not part of their own repositories, and some of their own public libraries, which were then managed in another repository of our svn, so that many assemblies were not found when built.

About question 1: As mentioned above, only the corresponding version can be found

and question 2: the first to find a lot of information and did not find a solution, and later from the source code management found a solution.

Scenario 1:

Drawing on Nuget's ideas, we use the Nuget server to manage some of our own public dependency libraries. An article about Nuget's management dependencies is in another blog post.

Scenario 2:

It is the external reference of SVN mentioned above. At that time, there was no way to go. So I translated these English explanations of Jenkins crazy. When I translated Ignore externals of SVN plugin, I found this scheme, that is, SVN can set external references, so update the repository. The dependent repository can also be updated, and then the Jenkins SVN plugin removes the Ignore externals option, and then fills in the SVN configuration of the dependent repository in the Additional Credentials option to update these dependencies to SVN. Within the space. After the above two problems are solved, there are basically no problems that are too difficult. This shows how important the science and norms of our source code management are.

Dozens of times the build failed, a bunch of messy quotes is how painful the understanding!

Fifth. Publish to the application server via FTP

After the build succeeds, Test.pubxml will specify the path of the package to be published (preferably in a workspace), following the idea of a way to copy the release package to the application server's root directory. Since our application server is a Windows system, it is not possible to copy the past via SSH, like a Linux system, when you can think of using FTP to upload directly to the application server.

1. Installing plugins and environments

Jenkins installs the plugin publish over FTP, the application server needs to open FTP.

2. Global configuration

System Management--system configuration Find publish over FTP configuration entry

Image

Name: a name that will be used later in the project configuration.

HOSTNAME:FTP Host name (port number default 21, in advanced can be changed)
USERNAME:FTP User Name
password:ftp Password3. Project configuration

Open our previously built project, find post-build operations, add post-Build Action step->send build artifacts over FTP

Image

Name: Select in the Global configuration

Source files: Choose your publish package path (this is the path relative to the workspace)
Remote directory: in which path is placed remotely (this is the path relative to the FTP root directory)
After the configuration is complete, click Save, Build!

Sixth. concluding remarks

As above, the basic realization of our automated release requirements, this period from six o'clock in the morning, almost noon completed, of course, is not as simple as described above, also encountered a lot of problems during the construction of about 100 times, only to finally succeed the first time. This article mainly introduces a kind of basic idea to realize the automatic deployment, of course, there are many solutions to realize our demand, even not only to Jenkins. And there are many details of this kind of solution, not mentioned in the article, such as: how to realize the automated NUnit unit test, how to build it on time ... because then I gave my team members a very detailed configuration document and trained many times, but it turns out that The more detailed they are, the more they will limit their own active thinking and hands-on abilities. This also led to the time when I went to do other work, we almost a year of time or stay in my half-day research results level, and the production environment is not used. In fact, the idea is the most important, with ideas we can solve our problems through a variety of ways, or suggest that we pay attention to problem-solving ideas, more hands-on, their own practice, to learn more! The problems and discussions on the implementation of the continuous integration and automation deployment of Jenkins under the. NET Platform You can leave a message under the article.

NET continuous integration and automated deployment