So I want to have a number of different websites running identical copies of binaries, but with differently transformed config files. These are different regional 'copies' of basically the same website (but connected to different backend DBs etc.)
I have a jenkins job which builds my asp.net site, e.g.;
MSBUILD
C:\Code\ProjectX\src\Website\adminsite.projectx\adminsite.projectx.csproj
/m /p:Configuration=Debug /p:OutputPath=C:\Code\ProjectX\build\Website\adminsite.projectx /t:Rebuild
When that job completes I want it to trigger a transform of the .configs, and a deployment of the binaries. Is there any recommended means of achieving this?
Right now there are only 2 different regional versions of the site deployed, each with their own web.config transformation file
I know that I could have each region BUILD its own copy of binaries, and do a straightforward deployment. But both regions will have identical binaries, so it seems like a waste of time for them to both kick off a build...
If both jobs try to build from the same source location msbuild seems to be producing artefacts in sub-folders of that location - so when both are kicked off at the same time they're tripping over eachother...
Any suggestions? :)
For what it's worth msbuild seems to ignore OutputPath when I provide that
That would have been ideal because I could just use something like;
/p:OutputPath=c:\Code\ProjectX\Build\$(Configuration)\.... etc.
I found that least wasteful way is to build (or "prepackage") once and include the trasforms into the artefact for environment-specific transformations and deployment later. Basically you'll have a custom MSBuild project, on build it'll call PipelinePreDeployCopyAllFilesToOneFolder target (less wasteful than Package since we don't need the final .zip) and redirect it with _PackageTempDir property and include all Web.*.config items, then on deploy you'll call the appropriate transform task and deploy via msdeploy sync.
Related
I have a "SOA" styled application, with a single solution containing almost 100 individual projects (which are a solution within them, i.e. they can be run independently). I have created a build and release definition in TFS 2018 and everything works perfectly.
The issue is if I make changes to a single service (out of 100), and check-in my code, the build definition is triggered which builds the entire application and then the release definition deploys the entire thing(100+) each time.
I don't want it. I need it to be specific to the service in which changes are made. Is there any way to do it?
Creating multiple build/release definition which is tied to the specific path of each service should solve it but I don't want to go down that road, because I will end up creating 100's of definitions.
Is there any other way to do it?
This is for a .Net application, hosted in TFS 2018 (On-premise).
The solution structure is as below:
AllWCFService.sln
|_Service1.csproj
|_Service2.csproj
|..
|..
|_Service100.csproj
Each Service can also be run and hosted independently.
This is my first question here. I apologize for any confusion.
As you have mentioned, by using Path filters on the Build definition should be the easiest solution.
With the proper path to the project in the Path filter only the proper Builds spin up, and any projects untouched do not trigger a build. Each build has it's own release which then deploys the specified app to it's own destination. As a ugly workaround, you could set up a group each with 5 services which will reduce 100's of definitions to 20's.
Otherwise, you have to customize your build definition/pipeline. Use some scripts to determine or judge which part of your Servicex.csproj changed base on your name.
Then call msbuild with /t option to build a single or multiple projects.
msbuild test.sln /t:project;project2 /p:Configuration="Release" /p:Platform="x86" /p:BuildProjectReferences=false
specify project file of a solution using msbuild
It will only build specified changed project and generated corresponding artifacts. Then add scripts in release to specify path according build generated artifacts to deploy each service.
Hope this helps.
On TFS 2018.2, I am building a release pipeline implying the use of :
Applications configuration files
PowerShell scripts
HTML/Markdown templates (for release notes)
My applications configuration files are located on a net share for now and that works fine but I would like to version them later on.
I was about to store other files on my existing TFVC repository but I did not find a way to get them (with their directory) without adding the entire repository as a release input artifact.
I do not want to add them to my build artifacts since these files will be used for all my releases, no matter the applications I am building.
What is the recommended way
to store these files
to get them on release execution ?
I have been tempted to use the library but I feel this would be a misuse of it since it has been designed for secure files...
The correct solution to this problem is something you've already hit upon: Add them to your build artifacts. In fact, it's better than pulling them from a separate repo for a very important reason:
Your deployment scripts are going to evolve along with your application. You lose the connection between "this version of the application was deployed with these particular scripts" if the scripts come from a separate location.
You have a lot of options to control the circumstances under which they get pubilshed/downloaded:
You can use conditions on the publish artifacts tasks to control when they get published
You can use artifact filters on the release definition to control when they get downloaded as part of a release
Build vNext tasks are an awesome improvement over the previous build process. One downside though is that I can't make some tasks conditional. I can create an additional build for every combination, but this clearly scales badly and causes lots of additional work if we have to change some other part of the build.
Instead I'd prefer being able to write my own PowerShell tasks that can call existing build tasks. There is at least one downside to this (if no build asks specifically for the vso-task the build agent won't download it), but considering we are using on-premise TFS and build agents I can live with this.
I tried to do something like the following:
$path = get-item "$env:AGENT_HOMEDIRECTORY\Tasks\NuGetPackager\0.1.56\NuGetPackager.ps1"
& "$path" -searchPattern $searchPattern -outputDir "$packageFolder" -configurationToPackage $configurationToPackage -nugetAdditionalArgs "$nugetAdditionalArgs -version $nugetVersion"
Sadly this causes the following error:
2016-04-12T09:50:22.3652811Z ##[error]import-module : Could not load file or assembly 'Microsoft.TeamFoundation.DistributedTask.Agent.Interfaces,
2016-04-12T09:50:22.3652811Z ##[error]Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find
2016-04-12T09:50:22.3652811Z ##[error]the file specified.
2016-04-12T09:50:22.3652811Z ##[error]At C:\Agent1\Tasks\NuGetPackager\0.1.56\NuGetPackager.ps1:19 char:1
Now one solution I found on the web indicates that I could add the looked for dlls to the GAC, but I really, really don't want to. Also clearly the tasks work just fine when called from TFS directly, so what configuration am I missing?
I tried adding the folder containing the dlls to the path and even call SetDllDirectory explicitly in the PowerShell, but neither of those help.
Environment: Windows Server 2012 R2 on both build agent and TFS server. TFS 2015 Update 1.
The Powershell task Host that's used by the build agent for 2015 RTM up to Update 2 is a custom host which does creative things to resolve assemblies and handle input/output. These tasks can't be called from outside the agent.
Plus, quite a few build tasks are implemented using Node, so you'll have to detect which one is which and invoke them accordingly.
The build tasks are being migrated to a new vsts-task-lib, which will support out-of-agent invocation. These would allow exactly what you want.
In the mean time you could take the existing tasks (they're a simple manifest plus script in most cases) and add one string parameter to the task in which you stick a variable which you can then treat as the condition. You'd need to replace all the standard tasks. Then push them again. if you keep the ExtensionID and the Task GUID the same, they'll act as in-place replacements. This is probably the easiest way to do what you want without having to perform all kinds of hacks that take away the Task's UI. Just set the version number to something ridiculously higher, like 100.0.1.83. that way you'll always end up using your version.
Note: the new builds are meant to be repeatable, in that calling the same build multiple times they always yield the same results. conditional actions can be captured in custom powershell scripts that are stored in source control. These can be executed as part of the workflow.
Having real problems creating artifacts in teamcity 6.5 (using TFS & MSBuild as the buildrunner if it makes any odds, which it probably does as any examples I find seem to use SVN...).
The Build works, so long as I enter no checkout rules.
If I understand it, I'll need to set up some artifacts, that themselves rely on checkout rules(?).
I have two builds that are identical other than the way they are kicked off.
One is initiated on check-in
One is initiated manually from within TC. This build is the Test Build
Assembly version numbers come from a single versioninfo.cs file that is a linked file in all projects in the solution. This method is detailed here : http://www.codeproject.com/Articles/328977/The-Right-Way-to-Version-Your-Assemblies and holds the version number thus:
[assembly: AssemblyFileVersion("9.1.0.0")]
Ultimately, I'm unable to copy the output of the test build to another location.
As it stands, the only output of a build is in the teamcity data directory, for example :
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project1\bin\Debug
C:\TeamCity\buildAgent\work\ceaaf65dc87ff856\Project2\bin\Debug
etc
I'd like to copy the output files (exes and DLLs) to an output folder which has the build number of the build on it
For arguments sake, lets say for the version number above, this would be to
c:\BuildServer_Output\SolutionName\9.1.0.0
Currently I have not been able to create artifact paths that actually do anything - i.e. to copy anything anywhere.
For instance I have acoupe of artifact paths, but nothing ever gets put into C:\BuildServer_TestBuilds -
+:Accounts\bin\debug* => C:\BuildServer_TestBuilds
+:BackOffice\bin\debug* => C:\BuildServer_TestBuilds
Am I getting no artifacts (and my artifact paths therefore ignored) because I have no checkout rules?
Any help would be appreciated.
I am pretty sure artifacts and checkout rules are completely independent. Artifacts just deal with what has been built. Checkout rules tell teamcity how to react to and checkout changes in the VCS.
It looks like your artifact paths are beginning with absolute paths. I have always found it easier to use relative paths with wildcards. That way I don't need to worry about where teamcity put the build. We use the following to get all dlls and exes to one folder
**\bin\Debug\*.*=>deploymentdir
Our build configuration page has an artifacts link and when we open it it will have things like
deploymentdir\common\bin\debug\common.dll
deploymentdir\common\bin\debug\common.pdb
deploymentdir\runner\bin\debug\runner.exe
In one of our other builds we use an msbuild script to flatten our output before putting it through the artifact process.
We do use checkout rules but we have not had to change our artifact paths to accommodate them.
I am pretty new to TFS and Build configuration tasks so forgive me if this problem has a simple answer.
I have a team project that is sort of a common library(CL) that contains dlls and apis that I commonly use throughout my projects. All my other projects reference files directly from the mapped folder for the CL on my dev machine.
I am trying to set up a build definition for Project A(Build server is on a different machine). I want always ensure that the CL is the latest before each build so is it possible to have the build definition pull the latest files first? The only other alternative is to start including the CL in of every project directly.
I tried adding a working folder for the CL, but it does not seem to get the files before it attempts to build project A. And then after when I try to rebuild after the failure, I receive a error saying that the CL working folder "is already mapped in workspace".
Instead of mapping in the sources, why not build the common library, deploy it to a common location, and have all the projects that use it reference it at the common location?
In addition to simply making more sense (it should be common binary, not common source), this greatly improves Continuous Integration builds. If several builds map the same source into their workspace, then when the common source is changed, all of those CI builds will be kicked off.