Skip to content

Release microservices guide #1891

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
renejeglinsky merged 4 commits into from
Jun 4, 2025
Merged

Release microservices guide #1891

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
59f7050
release microservices guide
Akatuoro Jun 2, 2025
7e8a4c5
Merge branch 'main' into release-shared-db
DanSchlachter Jun 3, 2025
6a57c62
Update microservices.md
renejeglinsky Jun 3, 2025
58df498
tidy up subsequent updates section
Akatuoro Jun 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 4 additions & 8 deletions guides/deployment/microservices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
synopsis: >
A guide on deploying SAP Cloud Application Programming Model (CAP) applications as microservices to the SAP BTP Cloud Foundry environment.
status: released
---

# Microservices with CAP
Expand All @@ -10,10 +11,10 @@ A comprehensive guide on deploying your CAP application as microservices.
[[toc]]


## Create a Solution Monorepo <UnderConstruction/>
## Create a Solution Monorepo

Assumed we want to create a composite application consisting of two or more micro services, each living in a separate GitHub repository, for example:
<!-- Those links aren't working links. Why do we use those? -->

- https://github.com/capire/bookstore
- https://github.com/capire/reviews
- https://github.com/capire/orders
Expand Down Expand Up @@ -906,12 +907,7 @@ resources:

#### Subsequent updates

- TODO...
Copy link
Copy Markdown
Contributor

@renejeglinsky renejeglinsky Jun 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is missing here before publication?

Copy link
Copy Markdown
Contributor Author

@Akatuoro Akatuoro Jun 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing really. The important part is to ensure shared-db is deployed before the others, so that the db model is compatible once the apps are deployed.

I've tidied up the section a bit.

- Whenever one of the projects has changes affecting the database, that triggers a new deployment of the `shared-db` project
- `git submodules` gives you control of which versions to pull, for example by `git branches` or `git tags`
- Ensure to first deploy `shared-db` before deploying the others


Whenever one of the projects has changes affecting the database, the database artifacts need to be deployed prior to the application deployment. With a single `mta.yaml`, this is handled in the scope of the mta deployment. When using multiple deployment units, ensure to first deploy the `shared-db` project before deploying the others.

## Late-Cut Microservices

Expand Down
Loading