NET continuous integration and automated deployment

Source: Internet
Author: User

Tags: Director Jenkin open source accumulation host name www download OSI project configuration

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

    1. 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

整个安装过程非常简单,基本上是傻瓜式按照提示操作即可,期间并未遇到问题,基本上10分钟左右就搞定了!接下来将介绍如何按照上述流程实现.NET下Jenkins的持续集成与自动化部署!

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!

Iv. 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:

借鉴Nuget的思想,使用Nuget服务器管理我们自己开发的一些公共依赖库。关于Nuget管理依赖的文章在另一篇博客里。

Scenario 2:

就是上面提到的SVN 外部引用,当时也是走投无路,于是疯狂翻译Jenkins的这些英文解释,在翻译到SVN插件的Ignore externals时,找到了这种方案,就是SVN可以设置外部引用,这样在更新版本库的时候就可以把依赖的版本库也更新下来,然后Jenkins SVN插件把这个Ignore externals选项去掉,然后在Additional Credentials选项里填上所依赖版本库的SVN配置,就能够把这些依赖也更新到SVN工作空间内。以上两个问题解决后,基本没有遇到太难的问题。由此可见我们的源代码管理的科学、规范是多么的重要。

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

V. 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 Password
3. 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!

Vi. 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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

Tags Index: