OpenEdge and Continuous Integration

Legal Notes There are various products used herein that are trademarks or trade names of their respective owners, and Progress Software Corporation Ltd makes no claim of ownership to, nor intends to imply an endorsement of, such products or companies by their usage.

Copyright © 2014 Progress Software Corporation. All rights reserved.

Page 2

Table of Contents Overview ................................................................................................................................................. 4 Components involved in Continuous integration ................................................................................... 4 Continuous Integration Setup ................................................................................................................. 6 1.

Source Control Setup .................................................................................................................. 6 1.1

Subversion (SVN) ................................................................................................................. 7

1.2

Roundtable .......................................................................................................................... 9

2

Build Automation Tool .............................................................................................................. 12 2.1

Configure ANT ................................................................................................................... 12

2.2

Configure PCT with ANT .................................................................................................... 12

3

Test Automation Tool ............................................................................................................... 12

4

CI Server Setup .......................................................................................................................... 13 4.1

Jenkins ............................................................................................................................... 14

4.2

TeamCity ........................................................................................................................... 19

4.3

Bamboo Server .................................................................................................................. 24

Workflow............................................................................................................................................... 30 Workflow with ABL Application ........................................................................................................ 30 1

Development......................................................................................................................... 30

2

Write Unit tests ..................................................................................................................... 31

3

Check-in the code to source control ..................................................................................... 32

4

Prepare ANT script to build source code and generate library ............................................ 39

5

Write ANT script to run the unit tests on the pl generated .................................................. 40

6

Get feedback for the build generated .................................................................................. 40

Appendix ............................................................................................................................................... 41 Sub-Version Repository Server ..................................................................................................... 41 Roundtable Team Server .............................................................................................................. 45 Jenkins ........................................................................................................................................... 48 TeamCity ....................................................................................................................................... 48 Bamboo ......................................................................................................................................... 51

Page 3

Overview In traditional software development, the integration of project source code doesn’t happen frequently. Developers can work separately for hours, days, or even weeks on the same source without realizing how many conflicts (and perhaps bugs) they are generating. They are producing robust code each time at the end of long integration cycle. The more developers are sharing the code, the more problematic this is. So, integrating the source code frequently is less painful than infrequently. But, if we commit frequently, we have a broken code. So, each time, the code is integrated, it should be tested. This involves many manual steps say:     

Integrating the source code when a Developer commits the changes to source code. Build/Release Engineer builds the Software after the integration. QA tests the build. Sends feedback to the respective developer in case of broken build. Mark the Software as usable.

All these manual steps should be automated. It is definitely worth automating a lot of things. Things that would take long time manually are very fast when automated. This can be achieved through Continuous Integration. Continuous Integration is a process which monitors your source code system, waiting for anybody to check in new code. The moment there is a check-in, Continuous integration process picks up all the latest changes, builds and tests the changes and sends out an Email or various other notification mechanisms with the details. Continuous Integration involves different components and different people. This document provides overview of Continuous Integration life cycle for OpenEdge Applications.

Components involved in Continuous integration Primary components involved in Continuous Integration Environment are: 



  

Development tool Tool to develop the ABL source code. This can either be a Procedure Editor or Progress Developer Studio for OpenEdge (PDS OE). Source Control Repository store, which contains committed source code. This can also be termed as Version Control. Source Control Client Client, from where ABL developer commits the source code to Source Control Repository. Build Tool Tool to automate compilation of source code to r-code. Testing tool Tool to automate the tests written for particular source code. Page 4



Continuous Integration Server Monitors the whole workflow, say every time developer commits code to Source Control, automatically checks out the code and starts building the project followed by automated tests and finally sends feedback to the developer with generated build artifacts.

Continuous Integration flow can be extended by including Source Code Analysis tools to analyze source code and identify potential problems. Also, you can include Agile and Bug tracking tools in Continuous Integration System. This document covers the flow with components mentioned above. People involved are:  

ABL Developer Build/Release Engineer

Continuous integration flow:

1. ABL Developer writes or modifies the source code and pushes them to the source control repository. 2. Continuous integration server initiates the process by pulling ABL source code from the source control repository. 3. After pulling code and artifacts from the source control system, Continuous Integration server launches the build process by running the build manager. 4. The build manager builds the application from source code. 5. The build manager runs ABL unit tests on the application built and generates reporting data. 6. The continuous integration server publishes the reporting data and notifies respective developer in case of any failure. 7. Finally, the continuous integration server publishes the generated artifacts to the production environment.

Page 5

Benefits of Continuous Integration 1. 2. 3. 4. 5.

Easy to identify and address bugs early in development cycle. Speeds up the development work flow. Availability of build on regular basis. Higher project quality as quality feedback will be received immediately. Avoids last-minute chaos at release dates

Continuous Integration Setup Build or Release Engineer is typically responsible for setting up and working with the Continuous Integration environment. This section provides details of configuring and setup of the elements used in Continuous Integration such as: 1. 2. 3. 4.

Source Control Build Tool Testing Tool CI Server

All of these systems can be setup independently and then configured in a CI Server to support Continuous Integration. There are many vendors available for each element used in Continuous Integration. This document provides details on setting up products from different vendors for few elements such as Source Control and CI Server: 



Source Control o Subversion o Roundtable CI Server o Jenkins o Bamboo o Team City

This document provides details of all the above mentioned products. Users can pick any one of source controls and CI servers for their setup.

1. Source Control Setup Source Control is also known as Version Control or Revision Control System. Version Control is system which records and tracks the changes made in a file or directory by a single user or group of users. The set of files or directories that are under version control system are referred to as Repository which is a central store to which any number of clients can be connected and read/write those files.

Page 6

There are many version controls available in market. Here is the list of few version controls and their general information: Tool SVN Round Table CVS

Availability Open Source Commercial Open Source

Mercurial Git Team Foundation Server AccuRev ClearCase PerForce GNU Bazaar

Open Source Open Source Commercial Commercial Commercial Commercial

Eclipse Plug-In Yes Yes Yes (comes as part of eclipse) Yes Yes Yes Yes Yes Yes

Vendor Apache Tugboat GNU GNU Microsoft Accurev IBM Rational Perforce GNU

This document provides details on setting up below version control systems and working with them. 1.1 Subversion (SVN) 1.2 Roundtable 1.1 Subversion (SVN) There are many Subversion binaries maintained by different vendors. Here, we are considering Visual SVN server. Visual SVN Server can be downloaded from here. Installation and configuration of SVN Server is detailed in the appendix. For committing the ABL source code to Subversion repository, we need a client. PDS OE is built on top of Eclipse and Subversion client is provided as an Eclipse plug-in which can be integrated with PDS OE. Configuring SVN client this way will make the check-in of ABL source code easier. Following are the steps to integrate Subversion client into PDS OE. 1. 2. 3. 4.

Launch PDS OE. Select ‘Install New Software’ option from PDS OE Help menu. Click Add button to add a repository for SVN Client. Provide the SVN client update site details (http://subclipse.tigris.org/update).

Page 7

5. Select the required ‘subclipse’ components.

6. Proceed with NEXT to agree the licence terms and click on FINISH. 7. Installation will take few minutes and PDS OE will prompt for restart. 8. Restart PDS OE for the changes to take effect. Now, we have the Subversion source control client available in PDS OE. So, to start committing the source code from PDS OE SVN client, we need to configure the client with repository details. Following are the steps to configure. 1. 2. 3. 4.

In PDS OE, open perspective SVN Repository Exploring. Open view SVN Repositories. Right click to add new Repository location. Provide the URL for the repository created.

5. Click on FINISH and provide user details to connect to the repository say ‘testuser1’.

Page 8

6. Observe that SVN repository gets created as below.

With this, Subversion client setup and configuration is completed and ready to check-in the source code. 1.2 Roundtable Roundtable Team, from Tugboat Software is another source control system developed using OpenEdge ABL and uses following OpenEdge Components.  

OpenEdge RDMS OpenEdge database acts as Roundtable Source Control Repository. OpenEdge AppServer OpenEdge AppServer is used to connect to the Roundtable Source Control Repository which is an OpenEdge database from any client.

Details on installing Roundtable Server can be found here. For committing the ABL source code to Roundtable Team Server, we need a client. Roundtable Team client is available as an Eclipse plug-in. As PDS OE is also built on Eclipse, Roundtable client can be integrated with PDS OE. So, with Roundtable client from PDS OE, it is easy to commit the ABL source code as soon as the developer changed the code.

Page 9

Following are the steps to setup Roundtable client in PDS OE. 1. 2. 3. 4.

Launch PDS OE. Select ‘Install New Software’ option from PDS OE Help menu. Click Add button to add a repository for Roundtable Client. Provide the Roundtable team update site details.

5. Select the required Roundtable components, say Roundtable Connector and Roundtable Team.

6. Proceed with NEXT to agree the licence terms and click on FINISH. 7. Installation will take few minutes and PDS OE asks to restart. 8. Restart PDS OE for the changes to take effect. Now, we have the Roundtable source control client available in PDS OE. So, to start committing the ABL source code from PDS OE Roundtable client, we need to configure the client with repository details. Following are the steps to configure. 9. In PDS OE, open perspective RTB Exploring. 10. Open view RTB Explorer. 11. Make sure that the configured OpenEdge Database and AppServer are running. Page 10

12. Select ‘Create new connection to RTB Repository’ option in RTB Explorer toolbar. 13. Provide the URL for the repository created. URL Format: AppServerDC://:

14. Click Test Connection button and provide user details to login.

15. Click on FINISH. 16. Observe that RTB repository gets created as below.

Now, Roundtable client setup and configuration is completed and ready for check-ins.

Page 11

2 Build Automation Tool For many languages, the build stage is more complex and follows a number of compilation steps, linkage, and building libraries/binaries or some languages platform-specific executables. Most modern compilers feature the ability to compile and link code to executable binaries via command line, thus enabling automated builds. These are performed from either the CI server directly, or by calling a specialized build tool (generic or language-specific) such as Apache Ant, Gnu make and MSBuild. A Build tool is needed to compile ABL source code. For OpenEdge ABL, PCT from Riverside Software (configured with Apache Ant) can be used as a build automation tool. Configuring Build automation tool for OpenEdge involves following two steps. -

Configure ANT Configure PCT with ANT (OpenEdge specific)

2.1 Configure ANT Apache ANT is bundled along with Eclipse and so this comes as part of PDS OE since version 11.3. If you are using PDS OE prior 11.3 version or if you want to work with the latest version of ANT, you can download ANT from here. ANT 1.8 or higher needs to be configured as both build tool and test tool requires ANT 1.8 or higher. We need to set environment variables for ANT_HOME and add ANT_HOME\bin to PATH parameter. 2.2 Configure PCT with ANT PCT (Progress Compilation Tools) is designed to compile OpenEdge ABL files. PCT can also be used to work with OpenEdge databases, provides different tasks for various database operations and can generate class documentation. Download new version of PCT from here. Copy the downloaded PCT jar to ANT_HOME\lib.

3 Test Automation Tool Continuous Integration allows us to run automated tests after each commit and send the feedback with results to developers. There are many types of tests that can be automated and can be included in Continuous Integration like unit tests, integration tests, regression tests, system tests, performance tests, GUI and Web tests. This document covers automating unit tests. A tool is needed to write unit tests and to automate them. ABLUnit is one such unit testing framework which allows ABL developers to write and execute the unit tests for OpenEdge ABL code.

Page 12

Following are few tools which offer unit testing framework for OpenEdge ABL: 1. ABLUnit 2. OEUnit 3. ProUnit This document covers the testing framework, ‘ABLUnit’ integrated with ANT (Build Tool) to run the tests automatically. ABLUnit comes with PDS OE 11.4 through which Users can write and execute Unit tests for OpenEdge ABL. Following are the steps to configure ABLUnit with ANT.  Copy ant-ablunit.jar from \java and place the jar in ANT_HOME\lib. Before this step, ANT should be configured. If not configured yet, click here to configure Ant. Alternatively, you can use ABLUnit Ant task provided by PCT. This can be downloaded from here.  Add ablunit.pl and OpenEdge.Core.pl (available under \) are added to PROPATH.

4 CI Server Setup A CI server acts as a monitor to the repository. It monitors the shared repository for any changes to check-out, builds the code, and runs unit and integration tests, then notifies results of the build and releases deployable artifacts for testing with a build label . Following is the list of Continuous Integration Servers available in market. Tool

Vendor

Availability

Build Tools

Plug-in availability

Jenkins/ Hudson

Oracle/Eclipse

Open Source

Ant, Maven

Eclipse

Cruise Control

GNU

Open Source

Ant, MS Build

Eclipse

Go

Thought Works

Commercial

Team Foundation Server

Microsoft

Commercial

MS Build

Visual Studio

Page 13

Bamboo

Atlassian

Open Source / Commercial

Electric Commander

Electric Cloud

Commercial

CodeBeamer

Team City

Commercial

JetBrains

Maven, Ant, MS Build

Eclipse, Visual Studio and IntelliJ

Eclipse and Visual Studio Ant, Hudson and Maven

Free / Commercial

Eclipse and NetBeans Eclipse, Visual Studio and IntelliJ

This document talks about few of the above Continuous Integration Servers say: -

Jenkins Team City and Bamboo

Every Continuous Integration Server needs following primary configurations:    

Source Control details (Repository location) JDK Installation details ANT Installation details Mail Server setup

As the document talks about different approaches with three Continuous Integration Servers, please follow the instructions for one of the CI Servers. 4.1 Jenkins Jenkins is an open source continuous integration tool used to manage building and deployment of project artifacts. To install Jenkins, refer Appendix for steps. Before using Jenkins, JDK and ANT installation details need to be configured. Following are the steps to configure. 1. Launch Jenkins in web browser and select Manage Jenkins link in the left hand navigation menu.

Page 14

2. Select Configure System link. 3. Provide JDK installation details. You can use JDK that ships along with OpenEdge installation or use the JDK installed. Select Install Automatically option to install JDK automatically.

Page 15

4. Provide ANT installation details.

5. Configure Email Notifications section with the SMTP Server in-order to send feedback through e-mail.

Creating a Job This section is a one time job for each release. CI Server needs to be configured with the details of the source code repository, Build automation tool and should be configured with build steps say compiling source code, generating library, running the tests and verifying the test results. 6. Create a Job To create a build job in Jenkins, Select ‘New Item, enter an Item name and select ‘Build a Free style Software Project’.

Click on OK button to complete job creation. Page 16

7. Provide Source Control details. - Roundtable Team - Subversion (SVN) 7.1 Roundtable Team: If the Source Control being used is Roundtable, select the Source Code Management option to None. o

Extract source code and related files from Roundtable Team repository using commandline interface provided by Roundtable Team. For this, create a batch file with following script. cd "C:\Program Files\Roundtable Team\cli" java -DRTBTeamCLI_URI=AppServerDC://172.21.32.80:3092 DRTBTeamCLI_UserID=testuser -DRTBTeamCLI_Password=password -jar rtbteamcli.11.jar Extract -Directory

o

Select Add Build Step option and select Execute Windows batch command option.

Provide the batch file and save. 7.2 Subversion (SVN): In Project Configuration page, Source Code Management details to Subversion if you are using SVN as source control or leave it to None if you are using Round Table as Source Control. 1. Provide Subversion repository URL as below.

Page 17

In Build Triggers section, select Poll SCM to trigger the build whenever there are changes in source code.

8. Select Add Build Step option and select Invoke Ant.

9. Provide the ANT Home configured in Jenkins and provide target name.

Same way, add following build actions for generating library, and to run the unit tests.

In this section, we need to provide path to the build.xml file and targets written for particular project source code and tests. This step can be configured once after the build.xml file is available for the project. Details on writing these files can be discussed in later sections in the document.

Page 18

10. Email notification

With this, the CI Server is configured with all the details needed. The Server starts monitoring the repository. Whenever the code changes are committed to source control, CI Server will trigger the build, run the tests, verifies the result of the test and send feedback to the developers regarding the quality if the build based on the test results. 4.2 TeamCity TeamCity is a Jetbrains project which offers Continuous Integration Server. More details on Team City are available here. 1. Log-in to the TeamCity Server with URL http://localhost:8000.

2. Configure email settings All the remaining settings like JDK, ANT and version control will be configured once after the project creation in TeamCity. Following are the steps to configure those details. 3. Select ‘Create Project’ option. 4. Provide parent project if any. 5. Provide the name of the CI project and description.

Page 19

Click on Create button. 6. Project will be created and the next step is to create a build configuration for the project.

Build Configuration 7. Click on Create build configuration button available.

8. 9. 10. 11.

Provide a name for build configuration. Click CREATE button to create build configuration. Version Control settings page will be displayed. Now, we need to provide Source Control details. The source control can be either of the below based on the source control you installed and configured.  Subversion (SVN)  Roundtable Team 11.1 Subversion(SVN) a. Select the version control type being used say Subversion. b. Provide the root name for version control. Page 20

c. Provide the SVN repository URL and its credentials. URL: https://NBHYDDPACHIPU7.bedford.progress.com/svn/PDSOERepo_SVN Username: testuser1 Password: password

d. Click on Test connection button to check whether able to connect to SVN repository or not. e. Click on Create button to finish creating the build configuration. 11.2

Roundtable Team If the Source Control being used is Roundtable, leave the version control settings as is and select the Build Steps option available at the left side menu.

a. Select Runner Type as Command Line and provide a name to step. Page 21

b. Select ‘Custom Script’ for Run option. c. We need to add script to extract source code and related files from Roundtable Team repository using command-line interface provided by Roundtable Team. Below is the example for custom script to extract files from Roundtable. cd "C:\Program Files\Roundtable Team\cli" java -DRTBTeamCLI_URI=AppServerDC://172.21.32.80:3092 DRTBTeamCLI_UserID=testuser -DRTBTeamCLI_Password=password -jar rtbteamcli.11.jar Extract -Directory

d. Click Save button to save the changes. Configure build steps 12. 13. 14. 15. 16. 17.

Select the Build Steps option available at the left side menu. Click on Add Build Step. Select Runner Type as Ant. Provide the step name say Build. Provide path to build.xml file or add the contents of build.xml file. Mention the target name, say build.

Page 22

In this section, we need to provide path to the build.xml file and targets written for particular project source code and tests. This step can be configured once after the build.xml file is available for the project. Details on writing these files can be discussed in later sections in the document. 18. Select Show advanced options to provide ANT home directory and JDK information.

19. Save the configuration. 20. Add new Build Step if required to run any other targets like to package and for unit tests.

Page 23

With this, the CI Server is configured with all the details needed. The Server starts monitoring the repository. Whenever the code changes are committed to source control, CI Server will trigger the build, run the tests, verifies the result of the test and send feedback to the developers regarding the quality if the build based on the test results. 4.3 Bamboo Server Bamboo Server is another Continuous Integration Server. This can be downloaded from https://www.atlassian.com/software/bamboo. For Installation, please refer to Appendix. Bamboo server by default runs on port 8085. Launch the server using http://localhost:8085 All the required repository and installations should be configured and can be used for all the build plans created in Bamboo server. Configure source repository 1. Select Bamboo Administration menu at the top right corner and select ‘Linked repositories’ option.

2. Now, we need to provide Source Control details. The source control can be either of the below based on the source control you installed and configured. Page 24

Click on Add Repository button.  Subversion (SVN)  Roundtable Team 2.1 Subversion (SVN) a. Select the Repository host as Subversion. b. Provide the version control details say Subversion. URL: https://NBHYDDPACHIPU7.bedford.progress.com/svn/PDSOERepo_SVN/ Username: testuser1 Password: password

c. Provide the Display name as ‘oe_svn’. d. Click the Save Repository button. 2.2 Roundtable Team Configuring repository step is not required in case if you are using Roundtable as source control. We need to provide check-out from Roundtable repository as an executable which can be used in later steps while adding build tasks. a. Now, select Server Capabilities option from left side menu. b. Select the capability as Executable to configure the script to extract files form Roundtable repository. c. We need to add script to extract source code and related files from Roundtable Team repository using command-line interface provided by Roundtable Team. Below is the example for custom script to extract files from Roundtable. cd "C:\Program Files\Roundtable Team\cli"

Page 25

java -DRTBTeamCLI_URI=AppServerDC://172.21.32.80:3092 DRTBTeamCLI_UserID=testuser -DRTBTeamCLI_Password=password -jar rtbteamcli.11.jar Extract -Directory d. Select Type as Command. e. Provide unique label for the executable say ‘oe_rtb’ and provide the ant directory location and provide the path to the batch script.

Click on Add button to complete configuring Roundtable repository details. Configure ANT and JDK 3. Now, select Server Capabilities option from left side menu. 4. Select the capability as Executable to configure ANT. 5. Provide unique label for the executable say ‘oe_ant’ and provide the ant directory location.

6. Click on Add.

Page 26

7. Now, add Capability type as JDK and provide JDK details.

Email Settings 8. Select Mail Server under Configuration category in the menu.

Click on Save button.

Page 27

Creating plan 9. Select ‘Create a new plan’ from ‘Create’ menu.

10. Create plan page will be displayed. Provide the project name and plan name.

11. If you are using Subversion (SVN), provide the version control details as ‘oe_svn’ for Source repository as we already defined this SVN repository configuration. If you are using Roundtable as version control, select option None.

Page 28

12. 13. 14. 15.

Leave the triggers section to poll the repository for changes periodically. Click on Configure Tasks. If you are using Roundtable as source version control, click on Add Task. Select Task Type as Command.

16. 17. 18. 19. 20.

Provide the task description. Select the executable as oe_rtb, the one configured in step 2. Add new task of type ANT. Select the executable as oe_ant, the one configured. In this section, we need to provide path to the build.xml file and targets written for particular project source code and tests. This step can be configured once after the build.xml file is available for the project. Details on writing these files can be discussed in later sections in the document. 21. Select the configured JDK. 22. Uncheck the ‘build will produce results checkbox’ and Save.

Page 29

23. Same way, add ant tasks for targets plGen and Test. Details on writing these files can be discussed in later sections in the document. For Test task, select option ‘The build will produce result files?’ and provide the results file location.

24. Click Create button to finish creating the plan. 25. From Actions menu, select enable plan to enable the build plan for running.

With this, the CI Server is configured with all the details needed. The Server starts monitoring the repository. Whenever the code changes are committed to source control, CI Server will trigger the build, run the tests, verifies the result of the test and send feedback to the developers regarding the quality if the build based on the test results.

Workflow We have the whole continuous integration setup ready, which continuously listens to the changes committed to Source Control to build the source code and run the unit tests in-order to qualify the build as usable. This section provides details on complete Continuous Integration workflow, which aims description on developing ABL code, writing unit tests, checking-in the ABL code to Source Control and configuring the CI Server to poll the source control for generating a build on daily basis.

Workflow with ABL Application 1

Development ABL developer develops an application in OpenEdge ABL using Progress Developer Studio for OpenEdge. 1. Launch Progress Developer Studio in a new workspace. Page 30

2. Create a new OpenEdge project. 3. Create an ABL class file. 4. Write your source code. In this example, a class file with name operations will be created with following content. USING Progress.Lang.*. ROUTINE-LEVEL ON ERROR UNDO, THROW. CLASS com.pdsoe.Operations: METHOD CHAR AppendProc(INPUT a AS CHARACTER, INPUT b AS CHARACTER): DEFINE VARIABLE res AS CHAR NO-UNDO. IF a = "" THEN DO: RETURN ERROR NEW Progress.Lang.AppError ("String must not be null", 200). END. res = a + b. RETURN res. END METHOD. METHOD CHAR getSubString(INPUT str AS CHARACTER, INPUT iPos AS INT): DEFINE VARIABLE res AS CHAR NO-UNDO. IF str = "" THEN DO: RETURN ERROR NEW Progress.Lang.AppError ("String must not be null", 200). END. res = SUBSTRING(str,iPos). RETURN res. END METHOD. END CLASS.

ABL Developer can work with ABL source code using either OpenEdge Studio or a Procedure Editor. 2

Write Unit tests Once the ABL application code is written, the functionality should be tested. So, unit tests should be written for particular piece of code say either a procedure or method or function in the application. This section describes writing unit tests using ABLUnit. 1. Create a new OpenEdge ABLUnit project in PDS OE. While creating project, select the project type as ABLUnit, so that all the required libraries mentioned in the section Configure ABLUnit will be added to Project’s PROPATH. 2. PDS OE provides tooling for writing ABLUnit tests. Write unit tests for your source code. The following example shows a simple test for the ‘AppendProc’ method in ‘Operation.cls’ written above in Development section.

Page 31

BLOCK-LEVEL ON ERROR UNDO, THROW. USING OpenEdge.Core.Assert. DEFINE VARIABLE oCls AS CLASS Operations. @Test. PROCEDURE testAppend: DEFINE VARIABLE res AS CHARACTER NO-UNDO. oCls = NEW Operations(). res = oCls:AppendProc("PDS ","OE"). Assert:EQUALS(res,"PDS OE"). END PROCEDURE.

If there are multiple tests, organize them in a suite and run them together using Run Configuration ‘Progress ABLUnit Application’. 3

Check-in the code to source control Once code is written or changed, each and every change in the ABL Source code and its unit tests should be committed to a source or version control system which maintains a central repository for source code. This section provides the details on committing the ABL source code to either of the source controls configured in Continuous Integration Setup say:  

SVN RoundTable

Go for specific section depending on the source control you installed and configured. If Source control plug-in is configured in PDS OE, ABL developer can use PDS OE or they can use window’s client. 3.1 SVN Using SVN Client from PDS OE: This section provides the details on committing the source code using the client installed in PDS OE. This can be done by using the Share Project option. 1. Select the project; right click to open context menu actions. 2. From Team menu, select Share Project action.

Page 32

3. In Share Project Wizard, select the option Use existing repository location and proceed to NEXT page. 4. If you wish to use the project name as the main folder in repository, select option Use project name as folder name otherwise you can specify the specific folder. And then proceed to the NEXT page.

Page 33

5. Provide comment related to the check-in and click on FINISH button to start the check-in procedure.

6. Switch to Team Synchronizing perspective and open Synchronize view to verify the files that are checked-in.

Page 34

In case, if ABL developer is not using Progress Developer Studio for OpenEdge (PDS OE) as development tool, they can use SVN Windows client to check-in the code. Using SVN windows client: This section provides details on checking-in the ABL code from Windows Explorer. This is an alternative to section Use SVN client in PDS OE to check-in the ABL code. 1. Navigate to the location of ABL code. 2. Right click to select Export option under TortoiseSVN context menu.

3. Provide repository url and click on OK button to check-in the code.

Page 35

Exporting the code copies the data to the SVN repository. 4. Provide user details.

5. Export progress details will be shown in Export dialog. Once completed click on OK button.

Page 36

6. Open RepoBrowser to check whether files added will be shown in Repository. 3.2 Roundtable This section provides the details on committing the source code using the Roundtable Team Server client installed in PDS OE. This can be done by using the Share Project option. Using RTB Client from PDS OE: 1. Select the project; right click to open context menu actions. 2. From Team menu, select Share Project action.

3. Select RTB as repository and proceed with NEXT button.

Page 37

4. In Share Project Wizard, select the option Use existing repository location and proceed to NEXT page. 5. Select the parent folder and then proceed to the NEXT page. 6. Provide comment related to the check-in and click on FINISH button to start the check-in procedure.

7. Switch to RTB Exploring perspective and open RTB Explorer view to verify the files that are checked-in.

Page 38

4

Prepare ANT script to build source code and generate library Once the source code is committed, the integrated code should build. To automate the builds, PCT (Progress Compilation Tool) provides a set of ANT tasks. For the complete list and details of ANT tasks, refer to http://code.google.com/p/pct/wiki/PCT. Now, we need to automate compile the ABL source code written. For that, create a build.xml file and write an ant script to compile the source code by PCT ant task PCTCompile. PCTCompile is an ANT task which compiles ABL files. Following is the sample build.xml format which is targeted to compile a set of .cls and .p files from ‘src’ folder (Ex, say the class file created in Development section) and copies the r-code to ‘build’ folder. More details on PCTCompile task can be found here.

From the r-code generated in ‘build’ folder, we need to generate a procedure library (pl) file. This can be done using the ANT task PCTLibrary. We need to add a new target section in the above created build.xml file to include PCTLibrary task. Following is the sample which generates pl file from the r-code files available in ‘build’ folder.

Page 39



This file needs to be configured in a build step in CI Server setup, so that CI server will trigger generating build once the CI build is triggered.

5

Write ANT script to run the unit tests on the pl generated This section provides details on automating the unit tests written in section 2 of workflow. Add the following target with ANT task name ABLUnit to the build.xml file. This ANT task is contributed form Progress OpenEdge, so ant-ablunit.jar file should be available in PATH while running the target.

This file needs to be configured in a build step in CI Server setup, so that CI server will trigger this once after the pl file is generated or build is generated. 6

Get feedback for the build generated Once there are commits to Source Control Repository, CI Server will run the build or project or plan configured for the project and sends feedback to the users list configured in plan. CI Server polls the repository and if it finds any changes in the code, CI Server will run the build or project again.

Page 40

Appendix As this section talks about the details of installing the third party products involved in Continuous Integration Setup, they might change based on the version you choose. Sub-Version Repository Server There are many sub version binaries maintained by different vendors. Here, we are considering VisualSVN server. Visual SVN Server can be downloaded from http://www.visualsvn.com/visualsvn/download/. 1. Run the installer and proceed with NEXT button in Welcome page in Setup Wizard.

2. Accept End User License agreement and click NEXT button to proceed.

3. Continue with defaults in Select Components page and proceed with NEXT button.

Page 41

4. Select Standard Edition to install and click NEXT button.

5. In Initial Server Configuration page, provide the repository location for the server which is a central store for all repositories.

Page 42

Provide port number and protocol details to be used. 6. Click Install button in Ready to Install page.

7. Click on FINISH once the installation is done. Installation information in Linux platform is available at http://www.linuxfromscratch.org/blfs/view/svn/general/subversion.html . Configure Sub-Version Server To work with SVN version control, we need a Repository which is a central store and users to access the SVN version control system. Following are the steps to create a repository in SVN. Page 43

Create Users: 1. 2. 3. 4.

Make sure that SVN Server service is started. Launch Visual SVN Server Management Console. Select ‘Users’ node, right click to select Create User action. Provide username and password for a new user say ‘testuser1’ as user and ‘password’ as password and click on OK.

5. Same way create one more user say ‘testuser2’.

Create a repository: 1. Make sure that SVN Server service is started. 2. Launch Visual SVN Server Management Console. 3. Select Repositories; right click to select ‘Create New Repository’ action.

Page 44

4. Provide the name of the repository say ‘Test_Repo’ and click on NEXT button to proceed. 5. Select Empty as repository structure. 6. Configure User permission and click on CREATE to create the repository. Repository gets created successfully and the wizard will display the repository details as below.

Roundtable Team Server Before installing the Roundtable Team Server, make sure that OpenEdge is installed in the respective machine and AdminServer is running. 1. Run Roundtable Team Server installer.

2. Proceed with defaults till Progress OpenEdge page. Page 45

3. Provide the OpenEdge installation location to the destination folder in Progress OpenEdge page.

4. Proceed with defaults.

5. Select Default option for installation type, so that an OpenEdge database with required roundtable schema and OpenEdge AppServer with configurations will be created and started.

Page 46

6. Once database and AppServer are created and started with required configurations, click on FINSH to complete the installation. 7. Run Roundtable Team config to add: a. Depot Directory b. User 8. Restart the AppServer to reflect the changes.

Page 47

Jenkins Standard version of Jenkins can be downloaded from http://jenkins-ci.org/stable-rc . Steps for installing Linux version of Jenkins are available at https://wiki.jenkinsci.org/display/JENKINS/Installing+Jenkins+on+RedHat+distributions.

Using the .war file of jenkins Jenkins war file is an executable WAR that has a servlet container embedded within it. Once downloaded and copied to the desired location, Jenkins can be started with the following command. java – jar Jenkins.war

This will start the servlet container. Once started the web based Jenkins user interface will be available at http://localhost:8080. To run Jenkins in any Servlet container like Tomcat server, put the war file in webapps directory and start the tomcat. Jenkins will be available at http://localhost:8080/jenkins.

Using native packages on other platforms For most of the platforms, Jenkins provides native packages. For more details see Jenkins Home.

TeamCity TeamCity can be downloaded from http://www.jetbrains.com/teamcity/download/index.html. Following steps describes the basic steps to be followed to install TeamCity. 1. Run the installer and proceed to the license agreement page.

2. Proceed to Install location selection page, and provide the desired destination. 3. Choose components to install. Page 48

4. Specify Server Configuration directory and click Install.

5. Once the installation is done, Agent properties dialog will be displayed.

Page 49

6. Edit the properties you want to change and click on SAVE button. 7. Run the team city server with user details

8. Provide user login details.

Page 50

9. Browser will be launched and TeamCity initialization will be shown.

Bamboo Bamboo Server is another Continuous Integration Server. This can be downloaded from https://www.atlassian.com/software/bamboo. a. Run the installer.

Page 51

b. Go through the installer using default options. c. Click FINISH when you get to the end. d. In start menu, find the Bamboo directory.

e. f. g. h.

Right click Install Service option and select Run as Administrator. Again select Start Service option from Start menu. Now, Bamboo Server is running and can be accessed using http://localhost:8085 . In Welcome page, provide the license key and create a new user account.

Page 52