Your onboarding journey
From your first account to your application running in production, technical onboarding runs through five phases. The path is the same for every vendor, whatever your contract looks like. This page is the map: what happens in each phase, who does it, and what has to be true before the next one can start.
openCode accounts
openCode, operated by ZenDiS, is where your build artifacts and your deployment repository live. Its registry is the binding registry for production deployments, and deployment to the platform is GitOps-based from openCode — so nothing else can start until your accounts exist. This is the step vendors most often underestimate.
You do: create an account for everyone who will work on the integration, nominate one of them as admin, and send us their names, openCode IDs and email addresses at vendor-support@govtechplatforms.de when you are done.
What you receive
- Your subgroup in openCode gitlab.opencode.de/govtech-deutschland/vendors, with your accounts added and one of them as admin
- Credentials for the openCode registry
Access to the Vendor Portal
We create and set up your organisation and team in the Vendor Portal.
What you receive
- Your organisation and initial team in the Vendor Portal, with workspaces to develop in and the ability to create and manage Landscapes
- OIDC client configuration for the Customer IAM
- Access to the Managed Services catalogue and to secret management
- Your onboarding support channel with Codesphere and your operational support channel with GovTech Platforms, named and set up
Integration on Shared Dev
Shared Dev is the shared development and staging environment where you build and prove your integration before approaching production. It is feature-par with production: what runs here runs in production unchanged. This is the substantial phase, and the one that decides whether the rest goes smoothly.
You do
- Deploy your application to Shared Dev using one of the available runtimes.
- Integrate with the Managed Services you need and the platform features like IAM and Observability.
- Decide your deployment path how to bring your application to production: Choosing your deployment path.
- Make the deployment repeatable: the same blueprint must be able to create another instance without anyone touching it by hand.
- Check your application against the platform's operating requirements and adapt it where it deviates - the self-assessment lists them.
Typical adaptation work
What most applications need, and roughly what it costs. Your self-assessment tells you which of these apply to you; the integration walkthrough covers each step in detail.
| Task | Typical effort |
|---|---|
| Containerise and automate deploy/upgrade/rollback | 1–2 days |
| OIDC integration | 0.5–1 day |
| Externalise configuration and secrets | 0.5 day |
| Untangle provider-specific dependencies | 0.5 day to audit |
We do
We track progress with you and help clear blockers. An onboarding walkthrough is available on request.
Integration test
The integration test checks that your application meets the platform's technical minimum requirements. It is not a quality test, not a functional test and not a product evaluation.
You receive the complete criteria catalogue when you are invited to the test, so nothing on the day should be a surprise. At a high level, it covers eleven areas:
- Your documentation, checked in advance
- Runtime environment, cloud capability and cloud agnosticism
- Deployment, configuration and secrets
- Identity and access management
- Data storage, backup and restore
- Availability, resilience and scaling
- Observability and supportability
- Service levels, RTO and RPO
- Security, compliance and data protection
- ITSM processes and support interfaces
- Exit, portability and handover
Before the test day
Your documentation is reviewed ahead of the test, not during it. Have these ready:
- All external connections, communication relationships and endpoints. These additionally need written approval from GovTech Platforms — without it, your application cannot go into operation.
- Interface documentation for every third-party system: protocols, data formats and authentication; error handling and logging; dependencies and prerequisites; test scenarios and their results.
- Your roles and permissions concept.
- Runbooks for operations and fault resolution.
- Healthcheck documentation — endpoints, logic, thresholds.
- Backup and restore procedures.
- Migration and exit mechanisms.
- Release notes and a vulnerability analysis for the exact version being tested.
The RTO and RPO values you demonstrate in the test are recorded in the protocol and become binding in your admission contract. Architectural constraints cannot be raised against them afterwards — so demonstrate what you can actually sustain in operation.
Work through the Definition of Done before requesting the test; every condition on it is checked.
Definition of DoneThe five conditions that make your integration completeProduction deployment & acceptance
Production is deployed from the immutable release tag named in your delivery package, followed by formal acceptance.
The production-side acceptance criteria for this phase are being finalised and will be published here once agreed. Until then, we will give you the current position for your application.
Typical pitfalls
These are some common mistakes that can hinder a smooth onboarding and deployment process:
A deployment that works once, by hand, but cannot be repeated from the blueprint alone.
Plan how new instances will be created and managed. Make sure the blueprint can successfully create a fresh instance from scratch in Shared Dev.
Provisioning steps that still need a human - which fails the Definition of Done however well the application runs.
Validate rolling out your application "unattended" by running it through the blueprint without any manual intervention.
Documentation that arrives late, which stalls the test before the test day.
Prepare the required documents during integration work, not at the end, and review them internally before requesting the test.
A delivery package that arrives incomplete, so production onboarding cannot start.
Use the delivery package checklist early and keep it versioned with your release artifacts to avoid last-minute gaps.