Is the most common way to structure configurations to map them to a particular coding project? For example we have one massive mainline branch in our SCM with some major sub-repositories and then 1000s of “projects” (generally VS.NET projects) under those repositories.
Generally it looks like this:
{companyname}{type}{product}{specific}
Is the best way for me to structure my configurations- to create a separate repository in Continua for each separate application? That seems like a lot of work. We literally have thousands of them. I was hoping to maybe create repositories at the product level and then if necessary create configurations at the application level- but I can’t tell how to specify that a specific file (or sub-repository) is mapped to a particular build configuration.
For example- if I create a repository at the product level- the source code files from any one of about 100 applications could trigger a build (we’d trigger on check-in). I’m not sure how to “map” the checked in files to the associated VS.NET solution (which is what we would build from).
Does this question make sense? I guess it is a moot point if you create a repository (in Continua) for every single VS.NET solution, but like I said- we have thousands and that would take forever.
Also- I see there is a way to Exclude files from triggering a build. Is there no way to specify include files? Say- I only want one file in my repository to trigger the build for that (VS.NET) project.
Thanks
Owen
Hi Omanske, thank you for posting
Which repository type are you using (SVN / Git etc)?
Is the best way for me to structure my configurations- to create a separate repository in Continua for each separate application?:
This will largely depend on the interdependencies within your codebase. A typically setup:
1 Product = 1 Continua Project (in your case: {companyname}{type}\ {product})
1 Product variation (eg dev / beta / release) = 1 Continua configuration (in your case: {companyname}{type}\ {product}{specific})
In this way common repositories (‘specific’ in your case) can be defined once, and placed at the Project scope level.
Each configuration would be set to build a specific branch (eg the beta configuration for the ‘Widgets’ project would build the ‘beta’ branch from the shared project scope repository).
Dependent repositories between projects can be defined once, and placed at the global level (and thus able to be shared by any configuration).
For example- if I create a repository at the product level- the source code files from any one of about 100 applications could trigger a build (we’d trigger on check-in).:
Triggers are defined at the configuration level and can be setup to look at any repository. Lets discuss this question further when we know which repo type you are using (there may be a way to refine how the repos are setup). We typically require a distinct branch if you wish to trigger a build on a specific portion of your sourcecode.
How to “map” the checked in files to the associated VS.NET solution (which is what we would build from). Also- I see there is a way to Exclude files from triggering a build:
See above. Additionally we do not currently have the concept of trigger includes or excludes (however this sounds like a useful feature given your use-case).
Posted By Pete Toms on 25 Sep 2014 08:08 PM
Hi Omanske, thank you for posting Surround SCM. And we can restructure our repositories if we need to- to a certain point. One of the difficulties is there are a large number of shared (common) architecture pieces used by all products.
Is the best way for me to structure my configurations- to create a separate repository in Continua for each separate application?:
This will largely depend on the interdependencies within your codebase. A typically setup:
1 Product = 1 Continua Project (in your case: {companyname}\{type}\ {product})
1 Product variation (eg dev / beta / release) = 1 Continua configuration (in your case: {companyname}\{type}\ {product}\{specific})
In this way common repositories ('specific' in your case) can be defined once, and placed at the Project scope level.
Each configuration would be set to build a specific branch (eg the beta configuration for the 'Widgets' project would build the 'beta' branch from the shared project scope repository).
Dependent repositories between projects can be defined once, and placed at the global level (and thus able to be shared by any configuration).
For example- if I create a repository at the product level- the source code files from any one of about 100 applications could trigger a build (we'd trigger on check-in).:
Triggers are defined at the configuration level and can be setup to look at any repository. Lets discuss this question further when we know which repo type you are using (there may be a way to refine how the repos are setup). We typically require a distinct branch if you wish to trigger a build on a specific portion of your sourcecode.
How to "map" the checked in files to the associated VS.NET solution (which is what we would build from). Also- I see there is a way to Exclude files from triggering a build:
See above. Additionally we do not currently have the concept of trigger includes or excludes (however this sounds like a useful featurem given your use-case).
Hi Omanske, thank you for the additional information, we are having a look internally to see what can be done for this kind of use-case (specifically for Surround). We will get back to you with some further details shortly.
Hi Owen
If I understand you correctly, you are using folders in a branch as projects? (much like working with source safe). We used to use surround here so I’m pretty familiar with it.
We have added a new Root Folder property to the surround repository type, which will allow you to point the repo at specific folders within the branch. The new property will allow you to create repos at the project level. I have just committed the change, so it still needs testing before it’s merged in, hopefully we’ll get it out to you either later today or tomorrow.
Filtering on triggers will take a bit longer (needs some thought on how best to implement it).
Vincent,
Yes- that is correct.
For example “PHC” is the mainline, BIN is the project type (these are binaries). The next level is products or components. The next level is usually specific applications which will have one solution and associated source code, but there may also be sub projects / applications.
If there is a better way to organize our source- I’m all for it. This has been carried over for almost a decade, from VSS, to Vault, to Surround. It was actually much less organized than it is now.
But if you can accommodate this structure- all the better.
Thanks so much Vincent. We have site-license for Finalbuilder and are just getting feet wet with automated deployments. I have already looked into TeamCity, other development groups in our company are already using Jenkins and some use TFS. I want to give Continua a shot because Finalbuilder is so awesome and you guys are so quick to make changes it’s unreal.
Owen
Hi Owen
I don’t have any real suggestions for organising the code, not something I would be comfortable advising on without having spent time with the code. We switched from Surround SCM to Mercurial a few years ago. With distributed version control systems like hg & Git, branching is quick and cheap (in terms of resources), sadly the same can’t be said for surround. I guess one thing to look is splitting out projects that do not change very often into separate mainline branches, and have those projects build the binraries and store them somewhere that can be accessed by other builds (nuget packages for example). There are so many possibilities.