Background

With GFE environment going away, there was a need to:

• setup Continuous integration platform for CONNECT development purposes and;
• provide a simulated test environment for testing different versions of CONNECT on multiple supported servers. 

To solve this, CONNECT team came up with an AWS based solution, that will host both the continuous integration (CI) and testing platform for CONNECT. For security purposes, CONNECT team set up an OpenVPN for accessing the CI and Configurable CONNECT. This guide is written specifically with AWS cloud in mind. However any cloud that provide Infrastructure as a Service (IaaS) can easily be replace AWS.

Configurable CONNECT

Configurable CONNECT allows testers and developers to spun a test environment instance with any CONNECT version deployed on any supported server. User also has the option of selecting  gateway to gateway/loopback  and standard/passthrough modes. Below is a screenshot of Configurable CONNECT:

Design Approach

Configurable CONNECT is built using AWS  infrastructure, and employs a number of AWS cloud tools/utilities and NodeJs. Listed below are the details of each Configurable CONNECT component:

AMI Default Image

Create a default EC2 machine/instance with the following software installed:

• Git 
• Java 1.7 and 1.8
• MySQL
• Apache Maven 
• Application servers including Weblogic(version: 12.1.11,2.1.3 and 12.2.1), IBM Websphere 8.5.5.3, Jboss EAP7 and Wildfly 8.2.1. Note: Make sure these servers are pre-configured for deploying and running CONNECT. For instance, the data-sources are defined on server, certificate installed and configured, server security setup appropriately if needed.
• Soap ui 5.4.1
• Create scripts to install CONNECT databases.
• Create scripts to start and stop application servers.

This default image will be used to create EC2 instances for Configurable CONNECT.

Repository for CONNECT ears

Use S3 Browser or any ftp site to host CONNECT ears.

Pre-configured CONNECT config files

• Configure internalExchangeInfo.xml / internalConnectionInfo.xml for gateway to gateway setup

• Configure exchangeInfo.xml / uddiConnectionInfo.xml for gateway to gateway setup

• Configure gateway.properties for standard and pass-through modes

NodeJs

ConfigurableCONNECT uses node js scripts to create a GUI where user can select CONNECT version, server type,  gateway mode( service type: standard/passthrough), gateway to gateway configuration and to deploy Admin GUI. NodeJs uses ssh to create EC2 instance from AMI Default image, copy the user selected ear from S3 browser,  copy connect properties, run CONNECT release specific database scripts and pre-configured files for different connect setups. Once  EC2 instance is created, NodeJs deploy selected CONNECT.ear. The instance is now ready to use for testing. User can also re-deploy an EAR, reset CONNECT database, run ValidationSuite  and View node js logs.

Launch CONNECT Manually

Once Configurable CONNECT successfully launches an EC2 machine, user can log in that box using software like Putty or Mobaxterm to view application logs, start and stop the server, deploy and un-deploy CONNECT ear.

Following Jenkins Jobs are used by CONNECT for CI purposes

1. Github Pull Request Validator
2. CONNECT_CI Stage_1
3. CONNECT_CI_LINUX_JBOSS
4. CONNECT_CI_LINUX_WEBLOGIC
5. CONNECT_CI_LINUX_WEBSPHERE
6. CONNECT_CI_MERGE
7. CONNECT_CI_NOADMINWS
8. CONNECT_COMMON_TYPES_CI
9. CONNECT_WEBSERVICES_CI
10. CONNECT_NIGHTLY
11. CONNECT_TAG

CONNECT Merge Build Process And Associated Jenkins Jobs

Step 1: Developer pushes changes to a *_integration branch within the Github repository at https://github.com/CONNECT-Solution/CONNECT (currently CONNECT_integration branch is the only one being watched by CI).

Step 2: Github Pull Request Validator build on Jenkins Master

• Triggered by: Jenkins polls respective Github *_integration branch every minute, and kicks-off a build when it detects that a change has been pushed.
• Executes: mvn clean install, which runs clean build, static analysis (SonarQube), runs junit tests, Validation Suite and checks code coverage results. Refer to Figure 1

Figure 1

Step 3: CONNECT_CI Stage_1  builds on Jenkins master. It executes Parallel Integration Testing on Jenkins Slaves

• Triggered by: PR merge on Github.
• Executes: mvn clean install -P weblogic,was,PD,DQ,DR,DS,DDS,AD,X12,DB,admingui . Copy the binary files generated in this step to appropriate Jenkins slave machines and then in parallel runs the various app server validation jobs (CONNECT_CI_LINUX_JBOSS, CONNECT_CI_LINUX_WEBLOGIC, and CONNECT_CI_LINUX_WEBSPHERE). Each of these jobs run all the soapui Validation Suite tests against the applicable application server. Refer to Figure 2.

Step 4: CONNECT_CI_MERGE Automated Merge of Git Commit to Stable Branch

• Triggered by: successful CONNECT_CI Stage_1 (that is, Parallel Integration Testing on Jenkins Slaves)
• Executes: Takes the original Github commit, which initiated the CI build on Jenkins Master (Step 2), and merges that commit to the stable branch (e.g., CONNECT). Refer to Figure 2. Also triggers  CONNECT_CI_NOADMINWS Jenkins job (builds CONNECT ear without Admin GUI web-services for Configurable CONNECT).

If build fails: It is the PR owner and PR merge's responsibility to address the failure ASAP.

• If the failure can be fix immediately then it is OK to submit another pull request to resolve the issue.
• If the failure requires any amount of time to resolve, then a "revert" commit needs to be submitted ASAP to back out the failing changes.
• It is important that failures are acted upon ASAP so that other branches can continue to be merged. A failed merge build will continue to fail until the issue is resolved, not even separate PRs can be merged if a previous one is failing.

Figure 2

CONNECT_COMMON_TYPES_CI

Jenkins runs the CONNECT_COMMON_TYPES_CI build whenever a PR is merged for CommonTypes repository. When successful, the CommonTypes snapshot is updated in sonaType(https://oss.sonatype.org/content/repositories/snapshots/org/connectopensource/) and it also triggers a build on CONNECT_WEBSERVICES_CI.

CONNECT_WEBSERVICES_CI

Jenkins runs this job when a commit is made against CONNECT-Solution/CONNECT-Webservices, the code is pulled, built, and the resulting jars are uploaded to Sonatype OSSRH (https://oss.sonatype.org/content/repositories/snapshots/org/connectopensource/).

CONNECT_NIGHTLY

Jenkins runs the CONNECT_NIGHTLY build every night after midnight. This build runs the entire suite of static code analysis tools (Findbugs, SonarQube and CheckStyle) as well as all of the automated regression suites. This build is run at off peak times due to the large amount of time to execute.

If the Build Fails

The team will be emailed about the failure during the execution of CONNECT_NIGHTLY and the fix will be put in according to team processes.

CONNECT_TAG

The CONNECT_TAG build is a manual build which can be kicked off to create a tag in github and optionally generate binaries.  This build is parameterized and takes the following inputs: