Test AutomationCI/CD pipelines

Continuous Integration (CI) comprises the steps from the source code to the deliverable (and tested) artifact, while Continuous Delivery (CD) describes the delivery of the artifact to the end user.

Nowadays, these two components interlock seamlessly, so that we are only talking about CI / CD pipelines. Basically, this is a classic EVA principle: Executable artifacts are generated and delivered from input data (source code, images, etc.).

Once set up, they form the backbone of software development:

• All recurring tasks are set up once and can then be repeated as often as required.
• The delivery of software is no longer tied to the specialist knowledge of individual team members, but is automated and documented.
• The CI/CD pipeline connects all systems involved (code management, test systems, artifact repositories and deployment).

For the implementation of CI / CD pipelines, some "standard solutions" have been established over the years:

• Jenkins
• TeamCity
• Bamboo
• GitLab
• Azure

Since we are repeatedly asked which system we recommend: We know from years of experience that there is no general answer. While the pipeline is written in one tool with Groovy, other tools use graphical interfaces or YAML. Depending on the project, the environment and the existing know-how, the decision for a suitable tool should be made. In principle, each of the tools is ideally suited for executing the pipelines and offers interfaces for the systems involved, from code management to deployment.

Just contact us if we can support you in choosing a suitable pipeline tool!

A pipeline definition can look slightly different depending on the CI / CD solution. To show you how a pipeline can be structured and what tasks it can perform, let's take the example of a declarative Jenkins pipeline. Such a pipeline consists of at least three parts:

• The specification of the machine (agent) on which the pipeline or parts of it are to be executed - the machine can also be set variably (any)
• The definition of the individual stages (stages / stage) that are to be run through (e.g. build, test, deploy) - these can run sequentially or in parallel
• The description of the steps that are to be carried out in the respective levels - this can be, for example, a shell script or a tool call to roll out application code again, to start a test, or to initiate another pipeline

With such a minimal pipeline, many important processes can already be automated. In addition, there are a number of other options to configure your CI / CD processes individually and to adapt them to your needs.

Tools for build management are to be distinguished from CI / CD pipelines. These tools are specialists for the first step in every CI / CD pipeline: The creation of an executable artifact from source code, images, fonts or libraries. In test automation, we use build management tools such as Maven or Gradle to build test automation solutions and provide them on the test system.

The last step of a pipeline is usually the publication of the software or the further deployment in live operation. Colloquially, these terms are often used synonymously, but describe different areas:

• Release: Provision of the software for further use, e.g. in an artifact repository such as Nexus
• Deploy: Rolling out the software provided in the release step to the customer. Often, container technologies such as Docker or OpenShift are used.

How often the deployment in the productive environment takes place depends on the specific project situation. In highly regulatory areas, there are often defined time windows for an update, while in agile projects, continuous updates are definitely possible.

Talk to us so that we can define and implement the perfect pipeline together!

We are happy to provide you with know-how, specific support services and associated license and support offers.