We are planning to categorize our project into different modules and each module will have its files linked to that.
Lets say Modules are structured as below and we call it as Module1 and Module2 and let be there 100 of such modules.
Module1
Views\Mod1.html
Controllers\Mod1Ctrl.vb
Module2
Views\Mod2.html
Controllers\Mod2Ctrl.vb
Once I make changes to files from many modules and make a check in- , from the changeset would I be able to get the modules to which the check in has been done.
It should be like once I give the changeset, I need to get the module list like Module1 ,Module 5 ...like that.
Is there any built in option in TFS 2015 to do that ?Is the labels for the same thing
Thanks for the help.
No, there isn't any built in option to configure this. The "Label" is used to take a snapshot of your files.
Labels let you take a snapshot of your files so that at a later date
you can refer back to that snapshot. By using your label, you can
view, build, or even roll back a large set of files to the state they
were in when you applied the label.
Related
We have a VSTS build setup. Currently we have a single repository hosting multiple services. We have a build definition per service, and triggers each only when the current service is touched, by a trigger pattern.
Now the issue is that each build definition hence the single repository makes the GetSource download the whole repo and also we do a clean.
I have been searching to see if there is a solution like the trigger where we can set a pattern, to just get a part of the repository downloadet. This should be to reduce build/download time.
A workaround might be to not make a clean each time or make multiple repositories. At the moment we would like to avoid the latter.
Let me hear if anyone knows of a good solution.
There is no way to specify the files to be downloaded in Get Sources step. Instead, VSTS will download the whole repo.
The workaround is set Clean option as false so that only the modified files and new added files will be updated in Get Sources step.
Our company currently uses TFS for source control and build server. Most of our projects are written in C/C++, but we also have some .NET projects and wouldn't want to be limited if we need to use other languages in the future.
We'd like to use Git for our source control and we're trying to understand what would be the best choice for a build server. We have started looking into TeamCity, but there are some issues we're having trouble with which will probably be relevant regardless of our choice of build server:
Build dependencies - We'd like to be able to control the build dependencies for each <project, branch>. For example, have <MyProj, feature_branch> depend on <InfraProj1, feature_branch> and <InfraProj2, master>.
From what we’ve seen, to do that we might need to use Gradle or something similar to build our projects instead of plain MSBuild. Is this correct? Are there simpler ways of achieving this?
Local builds - Obviously we'd like to be able to build projects locally as well. This becomes somewhat of a problem when project dependencies are introduced, as we need a way to reference these resources or copy them locally for the build to succeed. How is this usually solved?
I'd appreciate any input, but a sample setup which covers these issues will also be a great help.
IMHO both issues you mention fall really in the config management category, thus, as you say, unrelated to the build server choice.
A workspace for a project build (doesn't matter if centralized or local) should really contain all necessary resources for the build.
How can you achieve that? Have a project "metadata" git repo with a "content" file containing all your project components and their dependencies (each with its own git/other repo) and their exact versions - effectively tying them together coherently (you may find it useful to store other metadata in this component down the road as well, like component specific SCM info if using a mix of SCMs across the workspace).
A workspace pull wrapper script would first pull this metadata git repo, parse the content file and then pull all the other project components and their dependencies according with the content file info. Any build in such workspace would have all the parts it needs.
When time comes to modify either the code in a project component or the version of one of the dependencies you'll need to also update this content file in the metadata git repo to reflect the update and commit it - this is how your project makes progress coherently, as a whole.
Of course, actually managing dependencies is another matter. Tons of opinions out there, some even conflicting.
I would like to use some build parameters from Project 1 in Project 2. I know that I can make Project 1 a dependency of Project 2 and then access its build parameters as described in Dependencies Properties, but I do not want Project 1 to be built in response to a build of Project 2. For example, suppose I want Project 2 to be built nightly, while I only want Project 1 built monthly.
Is there any way Project 2 can access Project 1's build parameters under these conditions?
I would use a build configuration template that is shared between the two projects.
This means you can share properties between the projects, but also override certain ones in each individual project.
We use this for hourly builds that are not tagged and nightly ones that are tagged.
Then use a different build trigger to set one off nightly and the other monthly.
EDIT
I'll just expand slightly as a result of your comment.
In TeamCity we have 2 build configuration for the same project. One that builds on every check-in to give developers quick feedback on their contribution (build within 15 minutes). It does the following:
Builds the project in Debug
Runs all unit tests
Checks results of build into Subversion
The other configuration runs every night at midnight; it build everything and as a result takes a long time (around 45 minutes). It does the following:
Build the project in Debug and Release
Runs all unit tests
Builds Sandcastle documentaion
Checks results of build into Subversion
Grabs the Sandcastle output at an artefact so developers can easily download it.
As you pointed out this isn't as straightforward as one would like; however you can use the following to achieve it:
We use the Autoincrementer to share build numbers between the two configurations (they both increment the same build number when built).
We have a property on template that defines what artefacts to collect and is referenced from the artefacts field. The property is overridden on the second build config to define the sandcastle output to grab.
Sharing VCS Roots is mentioned on the documentation. Both our builds get the source from the same place, and tag the results to the same place. One VCS is most definitely all we need.
Bit of a long edit but I think it goes exactly on the lines of what you're trying to achieve. I appreciate I should have included this in the original answer.
HTH
Dependency is different from Build Triggering in TeamCity. If you make one project dependent on another ( artifact dependency ), it does not mean that the the latter will trigger the former.
Even when one project has been defined as dependent on another ( and also, even if not ) you have to specify explicitly the build trigger ( in this case a Finish build trigger ) for the dependent project to be triggered.
my situation is the following,
i have 2 big projects running separately on two machines (1 for each project) sitting of course on different locations and running different build.xml files.
i want to be able to run them both in 1 click and have the product in 1 library at the end.
meaning i can build my entire product in 1 click.
what us the best way to do so?
thanks for the help.
I would set up a build dependency between the two projects. This can be set up so that both projects always build back to back automatically.
When the first project is finished building, the artifacts you are interested in can be pulled over to the second project with the build dependency. Then, in that second project, you can configure the artifacts to be a collection of both projects' results.
You can read more about build dependencies here:
http://confluence.jetbrains.net/display/TCD6/Dependent+Build
If anything I said was too confusing, just let me know and I will come back to clarify.
Good luck!
So far, I've only used TeamCity as a continuous build server. No true integration. Now, I have the need to copy the output from one shared project to two other dependent projects, and kick off their automated builds in turn. That is, ProjectA and ProjectB both depend on ProjectC. All three are currently being built by TC when any commit occurs in their respective repositories. What we desire, is for the output of ProjectC to be copied and committed to ProjectA and ProjectB. Such a commit would in turn start the build process of both dependent projects. This seems like it would be a common scenario when talking about continuous integration. Is it not?
To clarify, we're using TeamCity v.4.5.5 (build 9103), SVN, and nAnt as our build runner.
EDIT: I mispoke when I said something about committing to another repository. They actually all three reside in the same physical repository, just at different levels in the hierarchy.
I don't know whether TeamCity supports this, but this should be easy to script by yourself - as a last step of build in ProjectC add a script that will checkout ProjectC directories (not whole repository, just a directory where you keep binaries of ProjectC) from ProjectA and ProjectB, copy all required files and commit with some autogenerated message - seems quite simple.
However - this is dangerous. Build of ProjectA and ProjectB could break because an API of ProjectC changed, or some untested part of code was broken. This could disorganize work of teams A and B. I would go for solution where new version of libraries are commited once a day / a week / any other time period.
Also, it might be a good idea to create an automated changelog - for example, if you trust quality of your svn log messages, you could create a changelog from all "new" commits included in commited release (or append current log message, if you decide to choose to push new libraries after every commit). This way teams responsible for ProjectA and ProjectB will be able to easily fix their build if new library breaks it - they'll know exacty what was changed, without need to check manually/ask team C.
Typically you don't commit build output to your repositories. Are you sure that's what you want?
You can make TeamCity copy the output (artifacts) from one build project into directories of another, but in order to commit it, you'll need to add some scripting, like a batch file or similar.
In newer versions of TeamCity you can define artifact dependencies, this will allow you to create a "library" as per your example and pull the artifacts of that build into your other projects. If you are using something like Node.js/npm to build a project, you will want to capture the output folder as well (e.g. 'dist') so that when you restore the artifacts you can unpack a single folder instead of a list of dependencies.
I can expand on this example if anyone is interested, just wanted to let folks finding this via Google that it is much easier to do now.