Distribute artifact built by bambooo to application server development prototype

At present, I encountered a problem: there is a SVN server, there is a build server used to build projects on SVN, there are many application servers, the application server program is generated by the svn project. Developers submit new code on SVN. After the version, they want to reflect it on all application servers without manual intervention.

(Bamboo is a commercial continuous integration server built by Atlassian, Australia. Based on Java, bamboo has more enterprise features than Hudson. Starting price: 10 $ RMB)

Because this requirement is too specific, there is no way to apply a ready-made framework. However, some technical combinations can be achieved at a very small cost.

(The word bug should be marked with "agent" next to the red dot)

The specific process can be described as follows:

1. The build server downloads the source code from SVN and executes the build.
2. After the build is successful, the listener plug-in will notify the deployment server of the artifact in TCP mode.
3. After the Deployment Server receives the latest artifact information, it will notify the agents on all application servers according to certain policies.
4. The agent receives information from the Deployment Server, including the program, which is placed in a specified directory.
5. The agent stops the server (or a specific application), replaces the relevant files, and then starts the server (or a specific application ).

There will be two types of customers to deploy the server, one is artifact, and the other is artifact.

For the sake of prototype simplicity, here we introduce any AIO, download library, and other things, all described in Java. Deploy a server as a class, agent as a class, and plug-in as a class.

The prototype is as follows:

Step 1

Create a project that supports building tools. Common Java building tools include ant and Maven, which are stored in the svn server.

Step 2

Configure a plan in bamboo to build the project just created. It is worth noting that this plan must be configured with artifact, that is, matching of the output. For example, if you created a Maven web project, it will generate a war file. The example configuration in the plan is as follows:

Select create Definition

Step 3

Although bamboo is very powerful, there is no such thing as TCP notification in the notification mechanism. We need to create a plug-in to deploy the server, what files are generated, and where they are stored.

All bamboo plug-ins, including Atlassian related products such as Jira, fisheye, and cruible, are implemented based on osgi fleix. We can follow the bamboo official documentation http://confluence.atlassian.com/display/BAMBOO/Tutorial+1+-+Getting+Started+with+a+Simple+Post+Build+Labeller to first create a build complete module, then just keep the run method, change it:

Public void run (buildable, buildresults buildresult ){
Final collection <artifactlink> artifacts = buildresult. getbuildresultssummary (). getproducedartifactlinks ();
For (artifactlink link: artifacts ){
Tcp_notify ("path" + link. GetFile (). getabsolutepath ());
}

}

Here, tcp_notify is used to connect to the Deployment Server and send a path command.

Package with "Atlas-MVN package" and put the package in the relevant directory according to the bamboo Manual (the V2/V3 directory is inconsistent), and the plug-in development is complete.

Step 4

Deploying servers may be a little complicated. I can simplify the implementation:

Public class builddeployserver {
Public satic void main (string [] ARGs ){
// 1 start server socket
// 2 for a client request, create a thread for processing
}
}

Class clientthread extends thread
{
Public void run (){
// 1. register the receiving client according to the artifact owner/consumer
// 2 if the customer is the consumer, all consumer clients are notified (the Consumer generally sleeps normally when there is no artifact)
// 3 if the customer is a consumer and artifact exists, artifact information is sent through agent communication.
}

}

Step 5

It is also very simple to compile the agent, as follows:

Public class appserveragent {
Public void main (string ARGs []) {
// 1. Establish a connection with the deployed server and send registration information
// 2 accept information related to artifact, such as file name, file content, and hash.
// 3 stopappserver or stopappmodule
// 4 sleep for a while
// 5 complete file replacement
// 6 startappserver or startappmodule

}

}

Step 6

According to the application server, deploy the server, build tools, and start the agent one by one, and then build a project in the build console, a series of automatic deployment work starts.

 

Of course, in the strict sense, automatic building and deployment still need to be improved. In my design, they are as follows:

1. The plug-in matches the project, file policy, and configuration of the output object.
   
2. After the number of application servers increases, the deployment server should be transformed into AIO, such as Linux epoll, Windows AIO, and Java NiO.
   
3. Network security issues to prevent spying or attacks.
   
4. Firewall traversal Problems
   
5. The Deployment Server pushes to the application server to change to pull, that is, the agent on the Application Server obtains the artifact from the server, reducing the scheduling burden on the Deployment Server. This requires resource encoding, multi-entry/thread.
   
6. The agent restarts the server in the middle of the night.
   
7. Logs and monitoring related to automatic deployment.
   

Welcome to the discussion!