Managing Build Configurations over time - archive, move, hide, disable

Is there an overall strategy for how to manage build configurations at their "end of life"? The scenario is as follows:

  • I have a number of build configurations created to build the release branch of a project.

  • The release branch is no longer in active development. Newer release branches exist.

  • Artifacts from these builds should be archived for historical reasons.

  • The list of changes and the build log for these builds should also be preserved for historical reasons.


There are a number of issues in the Issue Tracker related to the management of build configurations that reach a natural state of deprecation:

TW-4151: Ability to preserve build history for a build configuration copy
TW-5543: Allow moving build configurations between projects
TW-5697: Add the ability to move build configurations between projects.

Presumably these could be used to create an "Archived" project that would hold these builds.

TW-3396: Confusing Paused build configuration state: not visible on My Changes view (To avoid confusion and make the product more user-friedly, let's rename Pause/Activate to Disable/Enable.
)

This issue talks about creating an additional categorization for builds as "Disabled" or "Inactive".


Finally, this issue:

TW-5161: Allow to archive projects

Seems to be the only one I can find to address this entire use case from a high level so I'm curious if there has been some internal discussion regarding this type of functionality. I think supporting this type of "Archiving" will require changes in a lot of places, for example:

  • Configuring the visibility of projects based on their categorization

  • Configuring access roles for users

  • How artifacts are stored. Perhaps creating an "archives" section within the artifacts folder?

  • Being able to preserve not only artifacts for old builds but build messages as well


Thoughts?

- Rene

3 comments
Comment actions Permalink


Hello Rene,

You're right, currently TeamCity lacks the support for obsoleted projects. We internally also experience this problem.
I hope we'll add support for archived projects in a minor update for Calcutta, something like TeamCity 4.1.
This feature won't appear in 4.0, simply because we almost reached feature-freeze state.

The issue in tracker already mentions some places in TeamCity which are affected by project archive feature.
Archived projects won't be checked for changes (thus, will reduce load on SCM servers), won't appear on overview page,
will be hidden in many lists. You're right that specific permissions should be added to manage/view archived projects.

I didn't think about separate folder for artifacts of archived projects. Honestly, I'm not sure this one is required, given that
artifact access is usually done via TeamCity UI.

The mechanism to preserve particular build is based on clean-up policies. Probably, we should make some additions for
archived projects, though current schemes (+new cleanup rules in Calcutta) is rather flexible.

Kind regards,
KIR


- Rene



TW-5161: Allow to archive projects

Seems to be the only one I can find to address this entire use case from a high level so I'm curious if there has been some internal discussion regarding this type of functionality. I think supporting this type of "Archiving" will require changes in a lot of places, for example:

  • Configuring the visibility of projects based on their categorization

  • Configuring access roles for users

  • How artifacts are stored. Perhaps creating an "archives" section within the artifacts folder?

  • Being able to preserve not only artifacts for old builds but build messages as well


Thoughts?

0
Comment actions Permalink

Thanks for the reply. I certainly look forward to any new features that might help to better manage this kind of task. One thought to add regarding the separate archive folder for artifacts: This would enable having a separate backup strategy for archived artifacts vs. 'live' ones. Some of our build runs generate the actual installers which get deployed for testing and production so there's definitely a use-case to preserve these artifacts for the long term (as a way to historically track what has been deployed to production, etc...)

0
Comment actions Permalink

Hello Rene,

Regarding preserving artifacts and other information - that was the rationale behind "Pin" and "Tag" features in TeamCity.
Pinned builds are not a subject to cleanup process, and you can use tags to track builds went to production, deployed to particular servers and so on.

Kind regards,
KIR

0

Please sign in to leave a comment.