Pregunta

Our team works on a Agile methodology, having specialized teams in different parts of the product. Currently we have everything in a single Team Project, but we want to restructure everything so that we can apply a nice functional continuous build as right now, we have a build definition for our backoffice and one for our website. The problem is that if we make any change inside that team project, even if it's a text file, everything will go to queue and that is causing us big problems. So, this is how we would kill our problems:

# = Project Collection, > = Team Project, | = VS project
# PRODUCT
    > Core
        | CoreProject
    > Integrations
        | IntegrationsProject ( makes use of CoreProject )
    > Backoffice
        | BackofficeProject ( makes use of CoreProject and IntegrationsProduct)
    > WebSite
        | WebsiteProject ( makes use of CoreProject and IntegrationsProduct)

What this would allow us: - Diminish the amount of builds in the queue - Create branches of Integrations, which would not be changed often - Restrict access to Integrations and Core to specialized teams ( even if i know this can be done in other way )

Questions:

  • Is this the possible best solution for our requirements? If not, what would it be?
    • Let's say, working in WebsiteProject solution and having projects from diferent team projects in that solution, is it possible to checkin does projects?

Thanks!

¿Fue útil?

Solución

I suggest having one big team project, and just have 4 root folders in version control, and 4 build definitions that have the workspaces mapped to each of the 4 root folders. So long as you have the build workspaces mapped appropriately, checking in files to one folder, won't trigger the builds for the other folders.

This also allows you to set separate security permissions on each root folder should you wish.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top