Deploy SAP BTP Applications Using CI/CD with GitHub

[MaheshSirsat]

Deploy SAP BTP CAP Application Using CI/CD with GitHub

In this blog, I will show how I configured a CI/CD pipeline to deploy a SAP CAP application to SAP BTP Cloud Foundry using SAP Continuous Integration and Delivery and GitHub.

The application used in this example is a standard CAP application. The objective was to automate the deployment process so that a change pushed to GitHub could trigger the CI/CD pipeline and deploy the application to the configured BTP Cloud Foundry space.

The complete source code used for this example is available in my GitHub repository. Link 

Prerequisites

Before configuring the CI/CD pipeline, make sure the following prerequisites are completed:

1. The CAP application should be successfully deployed to SAP BTP at least once.

This is optional but highly recommended. A successful manual deployment confirms that the application itself, mta.yaml, services, and Cloud Foundry configuration are working before introducing CI/CD.

1. The CAP application source code must be available in a GitHub repository.
2. You should have access to the required SAP BTP Cloud Foundry space.
3. SAP Continuous Integration & Delivery must be available in your BTP environment.

Step 1 – Prepare the CAP Application

Before configuring CI/CD, I first verified that the CAP application could be deployed manually to SAP BTP.

This step is useful because it separates application deployment issues from CI/CD configuration issues.

If the application cannot be deployed manually, troubleshooting the CI/CD pipeline becomes more difficult.

For this example, the application is a standard CAP application containing the required CAP modules and an mta.yaml file for Cloud Foundry deployment.

A typical CAP project structure looks similar to:

cap-project/

│

├── app/

├── db/

├── srv/

├── package.json

├── mta.yaml

└── README.md

The mta.yaml file is particularly important because the CI/CD pipeline uses the project configuration to build and deploy the application.

Step 2 – Push the CAP Application to GitHub

After confirming that the application can be deployed successfully, I pushed the CAP project to GitHub.

The repository contains the CAP application source code together with the deployment configuration.

The GitHub repository becomes the source of the CI/CD pipeline.

Whenever a new commit is pushed, GitHub can send a webhook event to SAP Continuous Integration & Delivery.

Step 3 – Subscribe to Continuous Integration & Delivery

Navigate to:

SAP BTP Cockpit → Service Marketplace

Search for Continuous Integration & Delivery and subscribe to the service.

After successfully subscribing, assign the required roles to your user.

Navigate to:

Security → Users → Select Your User

Assign the relevant roles required to access Continuous Integration & Delivery.

Important Observation

After assigning the roles, I had to sign out and sign in again to BTP before the updated permissions were reflected correctly in the session.

This is a small step, but it is useful to check before troubleshooting access-related issues.

Step 4 – Configure Credentials

The CI/CD pipeline needs access to two systems:

• GitHub – to retrieve the application source code
• SAP BTP Cloud Foundry – to deploy the application

Therefore, I created the required credentials in Continuous Integration & Delivery.

4.1 GitHub Credentials

Navigate to the Credentials section and create the GitHub credential.

The GitHub credential is later selected while configuring the GitHub repository in CI/CD.

4.2 SAP BTP Credentials

Create another credential for the SAP BTP environment.

This credential will be used by the deployment stage to authenticate with the target Cloud Foundry environment.

Step 5 – Add the GitHub Repository

Now add the GitHub repository to Continuous Integration & Delivery.

Provide:

• Repository name
• Git repository clone URL
• GitHub credential

Select the GitHub credential created in the previous step.

Once the repository is created, CI/CD can use the GitHub repository as the source for the pipeline.

Step 6 – Configure GitHub Webhook

The next step is connecting GitHub with Continuous Integration & Delivery.

The webhook has two sides:

GitHub → Webhook Sender

CI/CD → Webhook Receiver

The purpose of the webhook is to notify CI/CD when a relevant change occurs in the GitHub repository.

6.1 Create Webhook Receiver in CI/CD

Create a webhook receiver event in Continuous Integration & Delivery.

Select the required value help and choose Create Credential.

Provide a credential name.

For the secret, use the Generate option and copy the generated secret.

The generated secret will be required while configuring the GitHub webhook.

6.2 Create Webhook in GitHub

Open the GitHub repository and navigate to:

Settings → Webhooks → Add webhook

Copy the Payload URL generated by Continuous Integration & Delivery.

Enter the secret generated in the previous step.

Set: Content type → application/json

Then click Add webhook.

The communication flow is now:

GitHub Repository ---(Push Event) --- >  GitHub Webhook ---> CI/CD Webhook Receiver

Step 7 – Create the CI/CD Job

Now create the CI/CD job responsible for building and deploying the CAP application.

Provide the required general information.

Select the GitHub repository that was configured earlier.

Step 8 – Configure Cloud Foundry Deployment

Navigate to:

Stages → Release → Deploy to Cloud Foundry Space

Select Deploy to Cloud Foundry Space.

Now open the target SAP BTP Cloud Foundry environment.

Navigate to:

BTP Cockpit → Cloud Foundry Environment → Overview

Copy the following information:

• API Endpoint
• Organization Name
• Space

Enter these values into the CI/CD deployment configuration.

Then select the SAP BTP credential created earlier.

The important point here is that the pipeline knows both:

1. Where the application should be deployed
2. How it should authenticate with the Cloud Foundry environment

Step 9 – Configure Build and Notification Options

Review the remaining job configuration.

Depending on the requirement, options such as the following can be configured:

• Build Retention
• Pipeline Stages
• Build Notifications After reviewing the configuration, create the job.

Step 10 – Test the Complete CI/CD Flow

At this point, the required configuration is complete.

The complete flow is:

10.1 Push a New Commit

Make a small change to the CAP application and push the commit to GitHub.

10.2 Verify the GitHub Webhook

Open:

GitHub → Repository → Settings → Webhooks

Check the webhook delivery generated by the commit.

This is the first place I check when validating whether the pipeline trigger is working.

If GitHub shows a successful delivery, the next step is to verify that CI/CD received the event.

10.3 Verify the CI/CD Webhook Receiver

Open Continuous Integration & Delivery and check the webhook receiver event.

The event should correspond to the GitHub push.

This provides a useful troubleshooting boundary:

1. GitHub Webhook Failed

         ↓

 Check GitHub configuration

2. GitHub Successful

         ↓

 CI/CD Receiver Failed

         ↓

 Check webhook receiver/configuration

3. Receiver Successful

         ↓

  Check CI/CD Job

Step 11 – Monitor the CI/CD Pipeline

Open the configured CI/CD job and check the pipeline execution.

The pipeline performs the configured build and deployment stages.

The execution may take some time depending on the application and build process.

Once the pipeline finishes successfully, the CAP application is deployed to the configured SAP BTP Cloud Foundry space.

Practical Observations

During this implementation, a few points were particularly useful.

1. Deploy the application manually first

I recommend doing one successful manual deployment before configuring CI/CD.

This confirms that the CAP application and Cloud Foundry deployment configuration are working independently of the pipeline.

1. Check the webhook before checking the pipeline

When a commit does not result in a pipeline execution, the first check should be the GitHub webhook delivery.

There is no benefit in troubleshooting the CI/CD job if GitHub never sent the event.

1. Validate both sides of the webhook

The webhook involves both GitHub and CI/CD.

Therefore, I found it useful to verify:

GitHub  à Webhook Delivery à CI/CD Receiver  à  CI/CD Job

This makes troubleshooting much easier because each stage can be validated independently.

1. Keep deployment credentials outside the application

The deployment credentials are configured in the CI/CD service rather than being stored inside the CAP source code.

This keeps authentication information separate from the application repository.

Troubleshooting Checklist

If the pipeline does not start after pushing a commit, check the following:

1.GitHub webhook

Verify:

• Payload URL
• Secret
• Content type
• Webhook delivery status

2.CI/CD repository

Verify:

• Repository URL
• GitHub credential
• Repository configuration

3.Cloud Foundry deployment

Verify:

• API Endpoint
• Organization
• Space
• BTP authentication credential

4.Application

Verify:

• mta.yaml
• Dependencies
• Required BTP services
  • Successful manual deployment

Final Result

Using this configuration, the CAP application can be deployed through an automated CI/CD pipeline.

The final process is:

GitHub → Webhook → SAP Continuous Integration & Delivery → Build → Cloud Foundry Deployment → CAP Application

The key benefit is that application changes can follow an automated deployment path instead of requiring the developer to manually execute the deployment for every change.

The complete implementation and source code for this example are available in my GitHub repository.

Conclusion

In this blog, I demonstrated how I configured a CI/CD pipeline for a SAP CAP application using GitHub and SAP Continuous Integration & Delivery.

The implementation covered:

• Preparing and validating the CAP application
• Storing the application in GitHub
• Configuring GitHub credentials
• Configuring SAP BTP credentials
• Connecting the GitHub repository
• Creating the CI/CD webhook receiver
• Creating the GitHub webhook sender
• Creating the CI/CD job
• Configuring Cloud Foundry deployment
• Triggering the pipeline through a GitHub commit
• Monitoring the webhook and pipeline execution

The important takeaway is that CI/CD configuration becomes much easier to troubleshoot when each part of the flow is validated independently - from the GitHub webhook through to the final Cloud Foundry deployment.