Setting up Continuous Integration Server

This page provides instructions to create a working Continuous Integration server that builds and deploys Elastic Path projects. A CI (Continuous Integration) server is a core requirement for team-based development. Elastic Path recommends Jenkins.

The objectives of this step are to:

• Automatically build all modules that were committed to source control in Preparing Elastic Path Source Code
• Deploy the resulting artifacts to the Maven repository manager

Containerization

Elastic Path provides tooling for building Self-Managed Commerce Docker-style containers. You can extend your continuous integration tools to build container images once the Self-Managed Commerce deployment package is built. For more information, see DevOps Tooling.

tip

CloudOps for Kubernetes includes continuous integration (CI) tooling for building and testing Self-Managed Commerce. Self-Managed Commerce container images built using the CloudOps for Kubernetes CI tooling can be run on any infrastructure that supports Docker-style containers. Even if you do not use CloudOps for Kubernetes for your production infrastructure, it may still be a suitable way to quickly provide CI tooling for your Self-Managed Commerce implementation team. For more information, see the CloudOps for Kubernetes documentation.

Continuous Integration Jobs

This section provides descriptions on the continuous integration jobs and associated commands. Setup continuous integration jobs only on the primary development branch. Automate the following jobs and associated commands:

Self-Managed Commerce

Builds the ep-commerce module and all modules within the ep-commerce module. This job builds:

• Bill of Materials
• Commerce Engine
• Health Monitoring
• Commerce Manager
• Cortex Resources
• Extensions
• Commerce Data
• Deployment Package

Root POM is ep-commerce/pom.xml.

mvn -B -U -e clean deploy -Pwith-deployment-package

Commerce Manager System Tests

Runs Commerce Manager Selenium tests and Cucumber tests using a deployed server as the test target.

Root POM is extensions/cm/ext-cm-modules/system-tests/selenium/pom.xml.

mvn clean verify -Premote -Dcucumber.options="--tags @smoketest" -Dfailsafe.fork.count="1" -Dremote.web.driver.url="http://<targetHost>:4444/wd/hub"

tip

Enable Test-ids on the target server using JVM (Java Virtual Machine) parameter -Dorg.eclipse.rap.rwt.enableUITests=true.

The deployment server and the test server might not be the same. To test against a remote Commerce Manager server, run the following command:

mvn clean install -Dcucumber.options="--tags @smoketest" -Dselenium.session.baseurl=${cmUrl} -Dep.cortex.url=${cortexUrl}  -f extensions/cm/ext-cm-modules/system-tests/selenium/pom.xml

Cortex System tests

Runs Cortex Cucumber testing using a deployed server as the test target.

Root POM is ep-commerce/extensions/cortex/system-tests/cucumber/pom.xml.

mvn -B -U -e clean verify -P!setup-local-integration-test -Dep.rest.baseurl=http://<cortex_host>/cortex -Dep.jms.url=tcp://${activemq_host}:61616 -Dit.test=CucumberRunnerIT

Notes

• Build modules with a valid settings.xml file

  The recommended practice is to use the maven/ci-settings.xml file in the ep-commerce/devops module and check this out from SCM (Source Code Management) at the beginning of each job.

• You can choose to add the following profiles to each of the Maven commands:

  • pass-build-even-if-tests-fail

    Using Jenkins, if a test fails then the build does not fail. This is useful because the build continues running and it will find all test failures. The build will turn unstable instead of passing or failing.

  • pass-build-even-if-code-compliance-fails

    Uses the same logic as pass-build-even-if-tests-fail but with regards to code compliance and code checking rules

Distribution Management

This section provides information on the distribution management for Elastic Path projects. To deploy artifacts to your Maven repository you need a settings.xml file with the repository URLs and credentials to match the distribution management defined for Elastic Path projects, as shown below:

The <distributionManagement> element is defined as follows:

<distributionManagement>
    <repository>
        <id>ep-releases</id>
        <url>${ep.releases.repository.url}</url>
    </repository>
    <snapshotRepository>
        <id>ep-snapshots</id>
        <url>${ep.snapshots.repository.url}</url>
    </snapshotRepository>
</distributionManagement>

Updating the ci-settings.xml File

This section provides details to configure Maven for continuous integration builds and distribution management.

1. Replace the following tokens in devops/maven/ci-settings.xml and commit to source control:

   • PROJECT_REPOSITORY_GROUP_URL: The URL of the project repository group used as the project mirror
   • PROJECT_RELEASE_REPOSITORY_URL: The URL of the project Elastic Path Releases Repository
   • PROJECT_SNAPSHOT_REPOSITORY_URL: The URL of the project Elastic Path Snapshots Repository
   • MAVEN_DEPLOYER_USER_NAME: The user name for the deployment Maven repository account
   • MAVEN_DEPLOYER_PASSWORD: The password for the deployment Maven repository account

   For using encrypted passwords in your ci-settings.xml, see the Encrypting passwords in settings.xml section in Maven Mini Guides.