One build _server_ per environment?
I'm struggling to understand the rationale of a client who wants to do this. I've never come across this before and I'm wondering if this is in any way standard practice for CI/CD build pipelines.
They have four environments, in addition to each developer's own personal machines, where they can run all of the parts of our product themselves:
dev: shared environment for integration testing features,
qa: shared environment for QA testers,
stage: shared environment where we smoke test deployments and do sprint reviews/demos,
production: the real world
The dev team is moving from Jenkins to TeamCity. Under Jenkins they had a single service account that had permissions to do everything it needed to do to build and deploy our apps, with one exception: database upgrades (schema and data) were not automatically deployed by the Jenkins jobs and had to be performed manually. They're taking the opportunity to fix that as they migrate to TeamCity.
The IT teams have given them a single "prod" build server to run TeamCity, and we've migrated 16 build configurations successfully (at least for the "dev" environment). We were planning on making the "deploy" build step smart enough to determine the target deployment server based on the Git branch or tag it's building (rather than have to maintain 64 configs across 4 environments)
However, IT/Security is now insisting (as part of a larger IT security effort) on separate service accounts for the environments (since the "builds" are now going to change production data) and each environments build config must run under the appropriate identity (since only those accounts will be able to touch their respective databases).
This would mean we'd either have to replicate our configs (and use the RunAs plugin), or setup four instances of TeamCity server.
IT is asking us to do the latter, which seems odd to me because the build server isn't really part of an environment - it's agnostic of the environment.
Either way, we'd be facing having to manage configuration across 4 different environments (or perhaps two if we go with prod and non-prod environments).
I should add that none of the development team will know the credentials for _any_ of the environment service accounts - an IT person will need to be walked through settings the passwords in TC RunAs config (or I guess for the build agent service if we end up with multiple build servers), which to me also makes having multiple service accounts pointless.
Anyone seen this requirement before?
Please sign in to leave a comment.
Hi,
as of seen, yes, this scenario is something that does happen in some instances. Multiple instances are common in very large installations with hundreds of agents and servers which might be in multiple locations. For a small amount of products which are distributed in several environments, usually a single server is used with multiple build configurations for managing the multiple environments. This said, the flexibility is there to handle all scenarios, as long as your IT/sysadmins can agree on what they consider most appropriate. It's not that one or the other are better per se, having multiple servers a
I'm not entirely sure what the runas plugin has to do with any of this, though. While it can cover some cases, it would make more sense that the IT admins would setup the users that run the processes with the appropriate permissions to run everything. Not that it's not impossible, but if you are running a restructure of the infrastructure, it might be worth keeping those things in check to reduce overhead.
Sharing the configuration between multiple installations should be trivial by storing them in version control: https://www.jetbrains.com/help/teamcity/storing-project-settings-in-version-control.html
As a last sidenote, we usually recommend more granular build configurations, as it improves visibility and traceability. Having a single configuration that performs different tasks depending on the branch or tag makes it take more effort to understand what has failed, while splitting this makes it easier to see straight away. The features of versioned settings (via Kotlin scripts) and templates help reducing the configuration overhead for this to very little.