Overriding existing projects on import
We have recently implemented a second TeamCity server, this new server will be for development and debugging of configurations, and the existing server will be for for production. This was required by management to reduce downtime of builds. I need some help figuring out the appropriate workflow for synchronizing work between servers on a reoccurring basis.
> The first thing I did was to export the production server and imported it to the development server. That went smoothly.
> The next step I took was to make some arbitrary changes to a sandbox project in development server and export just that project and import them back to the production server. This failed due to there already being projects/configurations with the same IDs. "Configuration file skipped (file already exists, but has different content)" in the logs. Older topics suggest changing IDs but that messes with build history.
> The only trick I came across was manually replacing the XML in 'ProgramData\JetBrains\TeamCity\config\projects'. I rapidly copied the contents of my dev server, deleted / moved the contents on the production server, and pasted the dev server contents in its place. On a sandbox test this seems to have been functional as again GUIDs and other values are retained, but I don't know if there are unspecified consequences I should know about. If this is actually a viable solution that confirmation would be useful to take back to management.
Really it would be nice to have a feature during importing that allows conflicts to be overridden by the incoming project.
Please sign in to leave a comment.
Hi!
Copying the files into 'ProgramData\JetBrains\TeamCity\config\projects' is okay and should not break anything.
Regarding a better way of doing that, I would suggest storing the configuration as Kotlin DSL code in the portable format. That way, you can point your production server to one branch in the settings repository and your test server - to another branch. After you test the changes on the test server, you can merge the test branch into the main branch.
Additionally, you probably could even skip having the test server if you want to, and create a copy of your project (or projects) on the production server and point them to the test branch of the repository with project configuration.
Here are a couple of tutorials on TeamCity Kotlin DSL if you are unfamiliar with it and would like to use it.
https://www.youtube.com/watch?v=AEYjAnR2-MY (video)
https://blog.jetbrains.com/teamcity/2019/03/configuration-as-code-part-1-getting-started-with-kotlin-dsl/ (blogpost)
If you need to, you can also store the settings in VCS as XML format instead of Kotlin DSL. Still, Kotlin DSL configuration in portable format requires less maintenance than XML after investing a little bit of time into a DSL tutorial. With Portable DSL configuration, you don't need to worry about duplicate UUIDs, and External IDs are easier to maintain.
As for reworking the Projects Import feature to allow resolving conflicts, it is unlikely that it would be done soon, unfortunately. Projects Import's purpose is mainly merging two servers that have different projects.
-Anatoly