Continuous building and deployment of projects based on Rational team concert and Gradle

Introduction

Continuous integration as a best practice in software development is being adopted by more and more project teams. Because the project is being built continuously, team members can find the errors introduced in the code earlier and make it easier to navigate to which part of the code the error was introduced by WHO. The entire process of project development becomes more manageable because of the continuous output of deployable parts, which are deployable, although they do not implement all of the functionality. The combination of continuous integration with test-driven development and other software development best practices can make code more robust and reliable. Here we'll start with how to build a continuous integration environment that includes continuous building and deployment of projects.

Next generation project Building tools Gradle

Currently, Maven has become the de facto standard in Java software construction. Maven provides predefined processes, build management, and a large number of plug-ins to easily build projects and provide rich functionality. The XML-formatted configuration file is also easier to understand, enabling beginners to master the use of Maven more quickly. But there are several drawbacks to Maven. First, the XML configuration file is understandable, but when the project build process becomes complex, the configuration file becomes very redundant and difficult to maintain. Second, Maven is based on Plug-ins, and all of the functionality built into it comes from plug-ins. When the plug-in does not provide the functionality you need, there is nothing you can do in the configuration file, which means that Maven's configuration file is not flexible enough. Third, when there is no plug-in to meet your functional needs, you need to develop a plug-in yourself, and this learning curve is a steep.

As a next-generation project builder, Gradle makes building projects easier and provides more powerful functionality and extended performance. Gradle provides the ability to compile, build, test, package, and deploy projects. Gradle has the following characteristics:

The build scripts for DSLs based on Groovy are very scalable and easier to organize

Provides a predefined build process and can be easily customized

Real support for multiple project builds

Provides a variety of ways to manage component libraries that are dependent and compatible with Maven and Ivy

can integrate and support Ant tasks

Gradle wrapper can be built in an environment without gradle

Team Collaboration development Tools Rational Group concert

The Rational Team Concert (RTC) is the first member of the software family based on the Jazz platform. Jazz is an extensible collaboration platform for managing the entire lifecycle of software development. The RTC architecture is based on client/server-side mode and is Cross-platform. On the functional side, the RTC provides support for work item integration, source control, reporting, and build management. The RTC brings a highly collaborative development environment to agile teams and is optimized for small and medium sized teams. The RTC also integrates interoperability with tools such as ration ClearCase, ration ClearQuest, and SVN. These features will provide great scalability for the team and help the enterprise build a better development team.

Project Building Overall architecture

Now we're starting to build a continuous build and deploy system based on Gradle and RTC. First of all, the overall structure of the introduction, in the latter part of the key parts for detailed description.

Figure 1. Schema diagram

Figure 1. Schema diagram

As we can see from the diagram, other tools have been used in addition to the Gradle and RTC mentioned earlier, and the role of these tools is illustrated in the analysis of the architecture diagram below. The entire build process is initiated by the RTC User, who initiates a build request to the RTC for a build definition. The build request can also be initiated by the Schedule defined in the build definition. After the RTC server accepts the build request, it sends a build task to the Jazz build Engine (JBE) in the building server, based on the build engine that the specified build definition associates with the build definition. Jbe is a service that runs on the build server, and it waits for the build task to arrive, and once the build task is received, the build task is performed according to the contents of the build definition. Here, Jbe executes the gradle command defined in the build definition to start the build process. Gradle will complete the project build process of compiling, testing, archiving, and deploying the build products to the application Server WebSphere Application Server (was) and Nexus. Nexus is a component management warehouse that can be used as a local mirror for the Maven central repository, or it can be used to manage its own components. Gradle is fully compatible with Maven's component warehouses. After Gradle finishes the build process or fails the build, Jbe collects the generated logs and returns them to the RTC server.