Naming Conventions in SAP BTP Cloud Foundry projects: Why Consistency is Key

When you’re managing multiple repositories, services and modules specially on cloud based projects or microservices projects (e.g: on SAP Business Technology Platform (BTP) Cloud Foundry projects), consistent naming conventions become your secret weapon. Clear names immediately convey purpose – you can tell at a glance what a repo or service does. This shared understanding boosts team collaboration and makes it far easier to navigate projects. In fact, experts note that “clear and consistent naming conventions are essential for maintaining organization, enhancing collaboration, and improving code discoverability”. Consistent names also simplify CI/CD pipelines: if each branch, repo or service follows a predictable pattern, automation rules (for deployments, for instance) become much simpler. Trust us, taking the time to name things thoughtfully saves headaches later.

Git Repository Naming

We prefix all our Git repos with our project code (e.g. rlopmar) and use a clear suffix to indicate the app or service. Project code could define a whole project to be delivered, a delivery team name, etc. For example:

• rlopmar-{appName}-ui – Frontend UI (SAPUI5/React/Angular/Vue/plain HTML5/...) application for {appName}.
• rlopmar-{projectName}-api – Backend service project for {projectName} (like CAP/OData APIs or any custom Python/Java/Node API).
• rlopmar-{projectName}-db – Database (HANA HDI) artifacts for {projectName}, if any. This is useful when complex HANA developments are needed. For simple data modeling, this might be skipped and will be defined directly in the API like in most of CAP projects.
• rlopmar-{projectName}-approuter – Standalone App Router for {projectName}’s applications. Interesting to manage it independently, so we have fine control over its deployments, routes, authorizations, bindings, etc.

I always use lowercase letters and hyphens (slug-case) in repo names. This follows industry best practices – “all repository names should be in lowercase and use slug-case (words separated by hyphens)” – because it’s more readable and avoids potential issues on case-insensitive systems. A disciplined pattern (prefix + project/app name + type) makes each repo’s role obvious without having to open it.

Branch Naming (Git Branches and CI/CD)

Inside each repo, we use a simple branch strategy tied to our environments:

• develop (default): our main development branch where feature branches get merged.
• test: code here is deployed automatically to the TEST environment. We do not push directly; changes come via pull requests.
• staging: stable code deployed for DEMO porposes. Usually a copy of PROD environment, and sometimes receiving pre-released code to DEMO it to stakeholders or early adopter groups
• main: stable code deployed to PROD (also only via PRs).

To support the integration of GitHub with Jira, the feature/bug branches include the Jira ticket ID. A common practice is to include the issue key in the branch name – for example feature/PROJ-123-add-login or hotfix/PROJ-456-fix-crash. In our team we might use a format like {JIRA-ID}_{short-description}, e.g. RLOPMAR-12_configure-ui5-data-source. Including the ticket key ties code commits and PRs back to stories automatically, so anyone can trace changes to requirements.

Following some industry trends, but optional, sometimes I prefix branches by type (feature/, bugfix/, hotfix/, etc.) as another convention to clarify purpose. In short, a branch name like feature/RLOPMAR-123-new-feature or RLOPMAR-123_fix-login immediately shows both the ticket and work description, which keeps our workflow organized.

MTA Module and Service Names (Infrastructure as Code)

In Cloud Foundry, we deploy using a multi-target application (MTA) descriptor. Here too, we apply structured names. We use two main patterns:

• rlopmar-{appName}-{moduleName} for app-specific MTA modules or service instances. For example, rlopmar-chatbot-api-srv might be the CAP server module for the chatbot app; rlopmar-chatbot-db-deployer could be a small deployer app that sets up the HDI schema.
• rlopmar-{moduleName} for project-wide services used by multiple apps. Examples: rlopmar-destination-service for a global Destination service instance, or rlopmar-xsuaa-service for a shared XSUAA instance.

This naming makes it clear which app a module belongs to, and avoids name collisions in Cloud Foundry. Every MTA module or resource gets a unique, descriptive name. For instance, all resources related to the chatbot project start with rlopmar-chatbot-…, whereas truly global services (like a shared destination) are simply rlopmar-{service}. This consistency helps when you scan the SAP BTP Cockpit or review logs – you know exactly where each service is used.

Unit Test Organization

We follow best practices for unit testing to keep tests predictable and easy to find. All unit tests live under a /test/unit/ folder at the project root. Inside /test/unit, we mirror the source code structure. So if your code has a file src/controller/App.controller.js, the test sits at test/unit/controller/App.controller.test.js (or .qunit.js). In other words, the folder structure matches, making it obvious which tests belong to which code.

Test filenames use the same base name as the code under test, with a .test.js (or .qunit.js) suffix. This is a common convention (for example, Jest and other test frameworks look for *.test.js files). So App.controller.js → App.controller.test.js. Each test suite (or module) is named with the path and function under test (e.g., "controller/App.controller - onInit"), and each individual test(...) has a clear description of its behavior. Clear naming and structure in tests, just like in code, makes it easier to run, debug and maintain them.

Summary of Conventions

All naming conventions start with a global project/team code (e.g. rlopmar), which is used to identify every component and part of each project (Jira tickets, code repositories, Teams/Slack channels, cloud instances, apps and services, etc.)

• Git Repositories:

  • Name pattern: rlopmar-{name}-{type} (e.g. rlopmar-orders-api, rlopmar-orders-ui, etc.).
  • Use all lowercase and hyphens (slug-case) for readability and consistency.

• Branches:

  • Main branches: develop, test, staging, main (environments: DEV/TEST/STAGING/PROD). No direct pushes to test/staging/main.
  • Feature/bug branches: include JIRA ID and short desc, e.g. feature/PROJ-123-add-login or PROJ-123_fix-login. This ties code to tickets.

• MTA Modules & Services:

  • App-specific modules: rlopmar-{appName}-{module}, e.g. rlopmar-chatbot-api-srv.
  • Project-wide services: rlopmar-{serviceName}, e.g. rlopmar-destination-service, rlopmar-chatbot-db.

• Unit Tests:

  • Test files in /test/unit/, mirroring source folders.
  • Filename = same name as code + .test.js (or .qunit.js) (e.g. App.controller.test.js).
  • Suites/tests named to clearly indicate the file/function being tested.

By following these conventions consistently, every developer instantly knows the “what” and “where” of code, services and tests. It might feel tedious at first (a typo in a name does mean renaming multiple things), but this discipline pays off in better collaboration, simpler CI/CD flows, and a codebase that feels orderly and self-documenting. Stick to the pattern and future-you (and the whole team) will thank you.