Your build is green, your deploy is queued, and then someone needs database access. The Slack thread turns into a scavenger hunt for credentials while CI logs roll by like rain. That’s the gap between automation and access control, and it’s exactly what Spanner TeamCity can close when set up right.
Google Cloud Spanner gives you a horizontally scalable, strongly consistent SQL database. JetBrains TeamCity runs your continuous integration pipeline with flexible build agents and strong version control hooks. But when the two meet, the invisible friction appears—how do you connect a CI runner to a cloud database securely without creating a key sprawl or an access zoo?
The logic is simple once you see it. TeamCity runs tasks under build agents, typically tied to service accounts or environment credentials. Spanner needs to verify those identities with precision, ideally using short-lived tokens or OIDC-based authentication instead of static keys. Aligning these correctly turns what could be a brittle connection into an identity-aware handshake.
When you integrate Spanner with TeamCity, start with identity mapping through a trusted provider like Google IAM, Okta, or any OIDC-compliant identity source. Assign roles narrowly based on the least privilege principle—only builds tagged to production, for example, should reach live data. Then automate key rotation and token refresh to happen inside CI steps instead of passing long-lived secrets. This keeps credentials off disk and audit trails honest.
If you see errors such as “permission denied” or stale token failures, check that TeamCity agents are using dynamic credentials at runtime, not cached service keys. The most common fix is reconfiguring your build steps to request a short-term token from your identity provider right before the database call. Once you switch to ephemeral auth, those errors vanish.