Continuous Integration
Continuous Integration (CI) and Continuous Delivery/Deployment (CD) are strategies aimed at solving problems around developing, testing and releasing software in a quick and consistent way. While CI encourages developers to integrate their code early and often in a main branch of a shared source control repository, CD focuses on automating the software delivery process so that teams can easily and confidently deploy their completed work to production at any time.
An introduction to Journey CI is provided below, and some guided examples using Jenkins and TeamCity.
What is Journey CI?
The Temenos Journey platform provides a capability for developers to benefit from CI best practice: namely, to integrate changes early and often with a main branch of a shared source control repository that is built automatically by a CI pipeline to produce deliverables. For example, developers working on Journey Manager services can push their code and unit tests to a shared Git repository, then instead of building those services in isolation and integrating them at the end of a development cycle, each developer integrates their code with the shared repository frequently, perhaps multiple times throughout the day. A developer or, preferably, a CI server runs a pipeline with required continuous integration steps; for example, validate (type check, run unit test) and build (make a deployable package).
Journey Manager includes a set of tasks for continuous deployment allowing teams to automate the delivery process, so they can easily and confidently deploy their work to various test, integration or production systems at any time. Journey CI aims to make integration a simple, repeatable process that is part of the everyday development workflow in order to reduce integration costs and respond to defects early. Working to ensure the system is robust, automated and fast while promoting a team culture that encourages frequent iteration and responsiveness to build issues is fundamental to success.
There are various options for when to trigger a CI pipeline such as after other projects are built, periodically (hourly, daily), or when a change is pushed to a repository. These last two options are commonly encountered; for example, building when code is pushed to a source control repository on completion of a work item, or a nightly build.
Application Package CI Example
A typical automated work flow for a CI/CD scenario with Journey Manager's Application Package may include the following steps.
- Checkout the Application Package (forms, functions, tests) from your source control repository (such as Git).
- Build the Application Package including any local unit tests.
- Deploy the Application Package to a Journey Manager (JM) test server.
- Run integration tests on the JM test server.
- Deploy the Application Package to a UAT test server.
