CODEWITHSUNDEEP
buildmsbuildcontinuous-integrationteamcity
lysergic-acid
lysergic-acid

Reputation: 20050

Continuously building and delivering only changed components

My team builds a .NET based software and several other components. Currently using TeamCity to do the continuous integration, MSBuild for simply compiling .sln file (plus some other small tasks such as unit tests).

Our source control is structured in a way, such that the repo contains many small "plugin" projects that get compiled after a single commit.

This makes it hard to only build only the changed components, but also to deliver only those later on as build artifacts.

Solutions such as setting the build target to "Build" instead of "Rebuild" may assist here, but it seems a bit too fragile, especially when dealing with a distributed build environment where the build may be carried on any number of build "agents", even ones that don't have the previous compilation output on them.

I am wondering what's the correct way to tackle this scenario? Obviously this is a known issue that's probably been handled and is handled by many.

We'd like to build and deliver (per build) a set of DLLs/components that were modified by the current build (by the code checkin).

What techniques can we implement to achieve this?

Upvotes: 2

Views: 1206

Answers (4)

Saurabh
Saurabh

Reputation: 36

One solution is "build" instead of "rebuild". If the builds runon multiple agents,then archive the build artifacts at the end of the build process at a shared location and copy those artifacts to the buildworkspace at the beginning of the next build (ie., automate archiving the artifacts at the end of he build and copying it at the starting of he build). The first build will fail because there will be no artifacts to copy from...hence keep that step as continue on failure or manually create that before. Running he first build. This will definitely increase he build time by a min or two....so ensure that the shared location is in the same network as your build agents...

Upvotes: 2

Suresh Mekala
Suresh Mekala

Reputation: 31

This is termed as incremental builds and has been part of SCM process for a long time. You Nant/msbuild scripts should be able to do both incremental builds and full builds from CLI ,else it is not termed as a complete independent build setup for your release process.

Hook up these scripts to CIE, like buildforge, jenkins, cnuisecontrol etc,.

The best way to achieve this is to use a switch in Nant/Ant/msbuild, so that when you run incremental builds, it will not delete old binaries, but compile just the latest changes to create just the code changes related binaries.

RTC Enterprise build does have a feature which does post delivery to your stream/branch, after it builds your local workspace after it compiles successfully, both incremental and full builds.

But i would recommend us to achieve this using build scripts rather than trying to achieve through a CIE tools, so that development stake holders have complete control over their build and packaging logic and removes dependency over build engineer (third party independent entity) who does not understand application compile logic, and will save lot of time from most inherent problems like wrong builds, human errors etc,.

Upvotes: 3

EricMinick
EricMinick

Reputation: 1477

You may need to restructure your source control such that each plugin sits in its own little project. Shared code they all reference would be in it's own project(s) producing common DLLs.

Liora mentions an asset repository. That's important as it will get you a place to store all these little libraries. In .Net land, I'm hearing more and more about NuGet for that.

The idea is that when a change comes in to a plugin, your CI system will pick up on that, pull in any common/shared libraries, and then execute the build, publishing a new version of that plugin. What happens when shared code changes is more interesting. You might just build that, or you might trigger builds of all of its dependents.

I touched on this a few years ago in an article I wrote on reducing the pains of build management: http://www.urbancode.com/html/resources/articles/build-pain-relief/components.html

Upvotes: 1

Liora Milbaum
Liora Milbaum

Reputation: 9

I am not sure I got the right problem. But, from what I think I understood, you need to work with some kind of assets library which will manage your build results artifacts. A followup actions can be configured once an asset is updated.

Let me know if this answers your problem.

Liora

Upvotes: 0

Related Questions