Continuous integration using webMethods

Knowledge base
, , , , ,
1
By Rahul Pahuja, Delivery Manager, Global Consulting Services, Software AG
Rupinder Singh, VP APJ, Middle East and North America, Global Consulting Services, Software AG
 
This article describes the basic concepts of continuous integration and how webMethods delivers features that make it relatively easy for development and operation teams to automate key tasks to enhance productivity and deliver the agility sought by every business.
 

What is continuous integration?

Continuous Integration (CI), as defined by TechTarget®, is a software engineering practice in which changes are immediately tested and reported when they are added to a larger code base. The goal of CI is to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. 
 
The basic principles of CI are:
  • Deployment is done from a single source repository, a different paradigm to for most webMethods customers
     
  • Frequent commit of code by developers, which requires tooling that allows developers to be able to check-in Integration Server (IS) code to the repository
     
  • Full visibility of the deployment process, which is controlled by a main job all the way through execution of unit tests to allow easy triage in the case where a build fails
     
  • Small, automated and fast builds, allowing iterative validation of a build and triages for small builds that are much easier than the typical large builds
     
  • Self-testing builds, in which automated unit tests validate each build and provide rapid feedback so that defects can be corrected immediately

Challenges of typical deployment architectures

Typical deployment architectures, as shown in Figure 1, present multiple challenges to achieving the goals of CI. The need to maintain detailed documentation and manually test and deploy opens your project up to human error and expensive problems. The manual approach to test and deployment is time consuming and complicated which can cause releases to be delayed. Large initiatives may have complex test scenarios and the development server will not serve as a reliable source.  To compound difficulties, the Version Control System (VCS) is often by passed to expedite deployments. This type of deployment architecture is also not well suited for small, repetitive test iterations.
976×562 160 KB
Figure 1: Typical deployment architectures pose risks for quality deployments.
 
The solution provided by CI to these challenges is a “reference server.” 
 

What is a reference server?

A reference server contains a clearly defined, reproducible version of a project on demand. It serves as the basis for deployment into target environments and can execute unit and regression tests vital for continuous integration. The reference server also serves as a record for audit purposes. 
 
Instead of placing responsibility on every single developer for deployment, it is now automated and centralized in a single source repository. Since the reference server is a concept, it may or may not be a single service or instance based on enterprise needs. 
 
A typical system landscape using a reference server, as shown in Figure 2, typically has the following key characteristics:
  • VCS serves as the central repository 
  • Multiple development servers for working on different project or versions
  • Reference server is “populated” or “refreshed” from the repository
  • Development servers can be partitioned based on projects, releases, types of users, etc.
  • Development workstations connect to the VCS directly 
  • Integration server connects to the VCS indirectly
Figure 2: Typical landscape for continuous integration leverages VCS and reference server
 

webMethods and CI

webMethods offers capabilities to support the four major CI components:
  • Source control integration
  • Automated build
  • Automated deployment
  • Automated unit testing 

Designer Workstation

provides source control integration for IS packages using Eclipse® plug-ins. It is a local integration server for local development, certified for use with SVN, Team Foundation Server (TFS) and GitHub®. Additional licensing is required to use this out-of-the-box feature.
 

Asset Build Environment

provides Ant scripts to check-out from source control and build scripts to generate Deployer composites.  Assets supported include Marketplace Web Services (MWS), BPM, tasks, IS packages and IS configurations. Samples with clear documentation on how to use these scripts are provided in the product install for SVN. Additional detail can be found in documentation for Deployer at http://techcommunity.softwareag.com/welcome-documentation.
 

Project Automator and Deployer Command Line Facility

are offered directly out-of-the-box to support automated deployment with no additional licensing required. The Project Automator facilitates automatic Deployer project creation. Wildcards are available to use in new projects and the Deployer Command Line Facility automates the deployment.
 

Global Consulting Services (GCS) webMethods Test Suite (WmTestSuite)

can help you automate unit testing for your organization. Included is the Designer Plugin for creating and configuring test cases. It allows non-developers to contribute to the tests and is built on proven frameworks such as JUnit, XMLUnit, HTTPUnit and XPath. Ant scripts are used to automate execution of test cases. To learn how you can obtain this performance-ready tool from GCS, visit our website at www.softwareag.com/consulting_tool  or contact: GCS-Tools@softwareag.com and see Marc Vietor’s article in TECHniques Issue 3: Add efficiency with smart add-ons: GCS tools for webMethods and ARIS.
 

CI in motion

You can use webMethods to implement CI with many of the common tools in the market, such as CruiseControl, CruiseControl.NET, Jenkins, Apache Continuum™ and Team Foundation Server. Let’s explore a sample scenario for deployment and unit test execution using webMethods and Jenkins, as shown in Figure 3.
Figure 3: Sample CI process using webMethods and Hudson & Jenkins.
 
Let’s explore the CI process: 
  1. Developer checks-in changes
  2. Jenkins checks-out changes
  3. Jenkins calls Asset Build Script
  4. Jenkins calls Project Automator script
  5. Jenkins calls Deployer command line scripts to push build to Reference Server
  6. Jenkins call ant scripts to execute GCS WmTestSuite test cases
  7. If build fails, Jenkins emails Build Manager
  8. If build passes, Build Manager tags the build in VCS
  9. Build Manager deploys build to the QA server from the Jenkins job
This scenario represents CI in local development. CI can also be executed in a central development topology. There are several ways of achieving automation for deployment and unit testing.
 

Key benefits 

CI is important to providing continuous delivery—the software development strategy that optimizes your delivery process to get high-quality, valuable software delivered as quickly as possible. By leveraging webMethods with continuous integration, you can achieve:
  • Shorter release cycles
  • Repeatable releases
  • Consistency across environments
  • Traceability
Implementing CI to achieve continuous delivery eliminates the guesswork out of what code base was deployed and when giving it end-to-end traceability and visibility. This greatly increases the quality of the product delivered to the business by the development and operations team, resulting in increased user and customer satisfaction.
 
Software AG Product Management and Global Consulting Services have joined forces to provide you with the right tools to support your pursuit of becoming more agile and delivering high-quality projects.