Continuous Integration using FlexDeploy

Continuous Integration is a practice where development teams integrate and test their changes in a shared environment on a regular basis, often several times per day.  This practice is used to eliminate the painful integrations which occur when merging large change sets across teams – a very typical pain point in traditional development lifecycles.  With Continuous Integration developers frequently commit their changes to a shared source control repository, using caution not to commit changes which don’t compile, are untested, or fail basic unit test scenarios.  An automated build process is used to build the application every time source code is committed (alternatively, some teams decide to schedule daily builds) .  Upon successful build the application is automatically deployed into a Test/Integration environment, and unit test cases are automatically performed.  The test case results are reported to the development team so that they can resolve any issues.  Any required changes are committed and the cycle repeats.  This feedback loop drives numerous improvements into the software development lifecycle:

  • Identify integration issues when the code change is fresh on the developer’s mind
  • Reduce long integration times attributed to infrequent builds and deployments
  • Return development focus to innovation and delivering business value
  • Increases visibility to software quality
  • Promotes collaboration across the team

While Continuous Integration is as much about people and process, technology plays a key role.  Having tools to support automating the build, deploy, test, and feedback loop are instrumental in any implementation.  Continuous Integration requires the following key components:

  • Automatically trigger builds upon source code commit
  • Automatically trigger deployments upon successful build completion
  • Automatically execute configured test cases
  • Report build, deploy, and test results, completing the feedback loop


FlexDeploy is a DevOps tool for Continuous Delivery and Release Automation which provides support for Continuous Integration right out of the box, allowing for a simplified tool chain.  Source Control Management integration is provided for Subversion, Git, Microsoft TFS, Perforce, CVS, and others.  FlexDeploy’s test automation framework provides integration with many popular testing tools, such as JUnit, TestNG, JMeter, and many more.

The following FlexDeploy project has been configured for a Java web application, with its source code stored in a repository.


The FlexDeploy build and deploy workflows are quite simple, as they utilize out of the box plugin operations (in this case Subversion and WebLogic).  The build compiles the source code and packages an EAR file as a build artifact.  The deploy workflow undeploys the existing EAR (if it exists), deploys the EAR packaged by the build, and executes any test cases associated to the project.


To execute unit tests for this project I have created two test sets of type Unit Tests.


The test cases are implemented using TestNG, which utilize Selenium to test the web application.  Using the out of the box TestNG workflow, we simply configure the parameters for the test.  The test definition for the Department Unit Test is shown below (the configuration for the Employee Unit Test is similar).


The testing strategy is used to associate the Unit Tests to the Development environment for our WebLogic instance (called ADF HR Server in this example).


By default, FlexDeploy enables on-demand build/deploy/test for the project.  To kick-off these workflows you can simply click on the buttons to bring up the request form.


To enable Continuous Integration for the project, we will create what are called triggers in FlexDeploy.  The Poll SCM Trigger polls the source code management system to identify if any changes have occurred for the project since the last build, and triggers a build if any changes are identified.  The Post Build Trigger fires whenever a build for the project is successfully completed.  Here I have configured a Poll SCM Trigger to monitor the trunk stream for the project.  I have also configured a Post Build Trigger to automatically deploy any project builds created from the project’s trunk stream to our Development environment.


Not let’s see it in action.  First, I will commit a change to the project’s source code in the trunk stream.


Within a few seconds after the code commit we see the build executing in the dashboard.


We can view the SCM change logs to see what code changes triggered the build.


After the build completes a deployment request is automatically submitted to the Development environment.


Upon completion of the deployment we can view the workflow execution and see the results of the tests associated to the project and testing strategy.  Here we see that the Employee Unit Tests and Department Unit Tests test sets were executed.  We can view the test case level detail by clicking on each of the underlying Test Definitions.


Continuous Integration is a vehicle which drives developer productivity, helps avoid “integration hell”, and improves software quality.  It enables developers to spend more time innovating and delivering direct business value, spend less time integrating and resolving build issues, and helps reduce the overall frustration that is often caused by less efficient processes.  FlexDeploy provides the necessary components to implement Continuous Integration practices right out of the box.


Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top