Skip to content

Project "Piper" User Documentation

An efficient software development process is vital for success in building business applications on SAP Cloud Platform or SAP on-premise platforms. SAP addresses this need for efficiency with project "Piper". The goal of project "Piper" is to substantially ease setting up continuous delivery processes for the most important SAP technologies by means of Jenkins pipelines.

What you get

Project "Piper" consists of two parts:

  • A shared library containing steps and utilities that are required by Jenkins pipelines.
  • A set of Docker images used in the piper library to implement best practices.

The shared library contains all the necessary steps to run our best practice Jenkins pipelines described in the Scenarios section or to run a pipeline as step.

The best practice pipelines are based on the general concepts of Jenkins 2.0 Pipelines as Code. With that you have the power of the Jenkins community at hand to optimize your pipelines.

You can run the best practice Jenkins pipelines out of the box, take them as a starting point for project-specific adaptations or implement your own pipelines from scratch using the shared library.

Extensibility

If you consider adding additional capabilities to your Jenkinsfile, consult the Jenkins Pipeline Steps Reference. There, you get an overview about steps that are natively supported by Jenkins.

The Jenkins shared libraries concept helps you to extract reusable parts from your pipeline and to keep your pipeline code small and easy to maintain.

Custom library steps can be added using a custom library according to the Jenkins shared libraries concept instead of adding groovy coding to the Jenkinsfile. Your custom library can coexist next to the provided pipeline library.

API

All steps (vars and resources directory) are intended to be used by Pipelines and are considered API. All the classes / groovy-scripts contained in the src folder are by default not part of the API and are subjected to change without prior notice. Types and methods annotated with @API are considered to be API, used e.g. from other shared libraries. Changes to those methods/types needs to be announced, discussed and agreed.