Skip to main content
Grand Central provisions each installation with a dedicated GitHub organization named bb-ecos-{installation}, such as bb-ecos-ecos. Within that organization, the platform repositories are organized into one or two parallel tracks. Understanding the tracks explains why you may see two sets of similarly named repositories in the same organization.

​
The two tracks

TrackRepositoriesOperated byIntended audience
Managedgc-{installation}-applications-live
gc-{installation}-self-service		Backbase Professional Services and GC DevOpsCustomers who acquire a managed, productized connector
DevHubgc-devhub-{installation}-applications-live
gc-devhub-{installation}-self-service		Customer developersCustomers who acquire a custom connector build, known as a slot
An installation has the track that matches what the customer acquires. The managed track is present for managed, productized connectors, and the DevHub track is present for custom connector builds, also known as slots. An installation can have one track or both.
The gc-devhub- prefix denotes the DevHub track, which customer developers operate. Repositories with the gc- prefix alone are the managed track that Backbase operates.

​
What each repository contains

Both tracks use the same two repository types. The difference is who operates them, not what they do.

​
*-applications-live

This repository holds the runtime and deployment configuration for the installation, which ArgoCD controllers consume to manage cluster state. The exact runtimes and namespaces vary per installation, depending on how the customer sets them up. Common runtimes include dev, stg, test, and uat. Each runtime contains:
  • Grand Central app: deploys the connectors for that runtime.
  • Secrets app: SOPS-encrypted Kubernetes Secrets and ConfigMaps stored in Git.
  • Istio app: networking configuration.
The repository references built connector images but doesn’t contain connector source code. You deploy by opening a pull request against main.

​
*-self-service

The GitOps control plane for the installation. The desired state lives in the self-service.tfvars file at the root of the repository, and you apply changes by opening a pull request against main. Through this repository you:
  • Provision user access to the organization and runtimes through the team_members section.
  • Manage the self-service, development, and applications-live GitHub teams.
  • Manage additional infrastructure and GitHub secrets.
  • Override default applications-live runtime reviewers.

​
Access enforcement

Repository names and prefixes don’t control access. Instead, GitHub team membership and Grand Central roles grant access per user in self-service.tfvars: 
team_members = {
  "developer@example.com" = {
    grandcentral = {
      roles = ["dev-rw", "dev-ro", "dev-apim-rw"]
    }
    github = {
      github_teams = ["self-service", "development", "applications-live"]
    }
  }
}
The gc- versus gc-devhub- prefix is an ownership and operating-model convention, not a security boundary. A user can reach whichever repositories their team grants allow. To verify who can access a given track, inspect the team_members grants in that track’s self-service.tfvars.

​
Where connector code lives

Neither the managed nor the DevHub applications-live repository contains connector source code. Connector implementations live in separate connector repositories that you create from a template through self-service.tfvars. Each connector repository holds the Apache Camel routes, the Maven project, and the connector configuration. For managed connectors, Backbase owns the connector repository and the published artifact, and the applications-live repository only references the built image. For more information, see Get started and Configure connectors.