We're using TFS 2017 Update 3 on premise for CI and CD. Our build server has two agents. We only have a few automated releases at the moment but are working on adding more. A typical release has 3 environments and each environment has X phases for the sake of logically separating/grouping activities. For example:
Phase 1 - Replace tokens (downloads the artifacts and replaces tokens)
Phase 2 - Deploy a database (skips artifact download, uses output from Phase 1, and deploys the db)
Phase 3 - Deploy a service (skips artifact download, uses output from Phase 1, and deploys a service)
Up until recently, because we only have few releases, only one release happened at a time and it's worked fine. Tonight I got bit.
What happened was Release 1 started and when it was in Phase 3, Release 2 was queued. Release 2 started Phase 1 on Agent 2 because Agent 1 was being used by Release 1. When Release 2 got to Phase 2, Agent 1 was now free so it performed Phases 2 & 3 on Agent 1. This lead to Phases 2 & 3 of Release 2 operating out of the folder where the release for the previous environment ran thereby resulting in the wrong settings being copied to the target environment. I hope that's clear. Essentially QA settings were copied to PROD.
I had figured that all Phases of an Environment started and finished on the same agent.
So, to achieve "Agent Affinity", is my only option to use 1 Phase? I'll miss the logical separation of steps. I don't see anywhere I can control that.
Thanks in advance for your help.
Phases should not depend on the output of previous phases. Use a single phase.
You can use task groups to logically group steps together.
Related
In VSTS build and release, I am now trying to separate out my code compilation and testing into separate phases for a build plan.
The first phase is fine, it does a git clean and gets sources and all that. However, the second phase should just start executing after the first phase is done. Instead it runs the git clean and reset and get sources AGAIN. Why would a phase do this if it is part of one build? I cannot for the life of me figure out a way to turn this off.
It is also entirely possible that I am thinking about this incorrectly and should be doing testing in the release pipeline or something like that.
Anyway tl;dr How do I turn off the get sources for a secondary phase in a build
The get sources step and clean setting is independent of a specific agent phase. It's in the top of the build definition when you create a new one.
An agent phase is a way of defining a sequence of tasks that will run on one or more agents. At run time, one or more jobs are created to be run on agents that match the demands specified in the phase properties.
There is no such related setting in a configuration of agent phase. You could not turn off the get sources for a secondary phase in a build.
As a workaround, you could try to turn off the entire get sources step in the build definition, and directly use powershell script to do a get source in single agent phase. Detail steps please refer my reply in this question: Is it able to ignore/disable the first step Get source in vNext Build?
Moreover, about the concepts and features in agent phase, please refer this tutorial: Phases in Build and Release Management
I have played around with jenkins pipeline and like it a lot.
Our team has a project which follows structure described below
A -> B -> C
Debug Debug Debug
Release Release Release
Basically, project C depends on project B and project B depends on project A. When we mark A as a successful build, it has to pass both debug and release build. LKGB is marked as a project that does not break either debug or release build.
I wonder how can we translate this logic into pipeline code, building debug and release are more like "Sub Projects" since they run on different machine".
I tried using "parallel jobs" but it will make the debug/release output mixed together.
I tried out the "multi config" plugin and it serves our need, is there an equivalent version for jenkins pipeline?
I have a Visual Studio solution with one SSRS project, two SSIS projects, one SSAS project and one SQL Server project. I'm using TFS2013 Update 4.
I'd like to deploy this solution using TFS Release Management in two environments. First environment should be "populated" after the developer's check-in and in the second environment the projects should be deployed only in the next night (during the day the environment is used by the testers and a new deployment can affect their data).
It's possible to achieve this with TFS Release Manager 2013.4?
Update 1:
A single gated check-in build is taking too much time and that's why in this moment I have gated check-in builds separate for each project in order to keep the developer's waiting time to minimum.
Update 2:
The current setup is with five gated check-in builds that are building and deploying each project to the first environment and one nightly build that is building and deploying to the second environment the entire solution.
Add an additional "collector" build, that you automatically queue from the others whose purpose is to collect artifacts and be the reference for Release Manager.
In other words, say you have five CI builds, one for each project named CI1 to CI5. In each CI post-test script you run a similar command
TFSBuild start /collection:%TF_BUILD_COLLECTIONURI% /buildDefinition:Collector /queue /msBuildArguments:CIDrop=%TF_BUILD_DROPLOCATION%
to queue the Collector build.
This latter collects the artifacts from the parent build and the last know good artifacts of the remaining CI builds and copies them to its drop location.
Now you can use Release Manager as usual on this Collector build.
We're using TFS to follow a pretty standard agile build process:
Nightly builds from latest source code
Build to staging server every 2 weeks
Build to production server every 4 weeks
I've got 1 and 2 set up in TFS and working great. However, I'm struggling a little with #3. If I just set up a "normal" build, it will pull the most recent source code and use that to push to the production server. But what I really want is to move the code from step #2 to the production server since it's already been vetted by the QA team.
I thought about doing a custom build template that uses XCopy or something along those lines, but then the issue is how to update the configuration strings.
I was following this article, which seems to be exaclty what I want, http://www.asp.net/web-forms/tutorials/deployment/configuring-team-foundation-server-for-web-deployment/deploying-a-specific-build, but it is not working.
How do you all accomplish this?
So this is a slightly easier way to achieve 3. if you have achieved 2.
Let your production build definition stay as it is. However to compile the same changeset that was used to compile your staging build in step 2 (which has now been vetted by QA), when you queue a prod build then on the parameters tab expand the Advanced section and find the "Get Version" property as shown below.
In here you can specify the same TFS changeset that was used to build your build in step 2. Assuming this changeset is number 84, you would write (exactly)
C84
if you compile labels then for a label named - "For build xyz" you specify
LFor build xyz
Note that "C" and "L" above are intentional.
Hope this helps.
We have a different branch for production and code only gets merged into the production branch after passing Q&A.
That allows us to apply hot-fixes to production code with changes directly on the production branch (those will eventually get reverse integrated into main then dev) while development continues on the development branches.
Once code in the development branches are ready for Q&A, it is merged into the Main trunk.
CI and nightly builds are done on the development branches - the difference being nightly builds having more comprehensive automated tests
When you are using Team Foundation Build to build a project for multiple environments, do you do one build for all environments, or keep a separate build script for each environment?
Think of the case when I might want the workspace version on my build server to build in DEBUG mode for QA and RELEASE mode for UAT. Should one build request do both of those builds, or should I do a build for QA when I need a QA build, and do a build for UAT (using a label) when I need a UAT build?
One caveat might be that we might want the build to be automatically copied to the server for one environment and not the other. Perhaps we want the bits to go out to QA and not UAT, or we want the bits to go to UAT and not QA.
Let me know if you need further clarification.
Mark
Will you always or almost always want to build both a QA and UAT release at the same time? If so, it makes sense to build them in the same project. If not, I'd separate them.
There may be other things you want to take into consideration (additional tasks in targets that may be specific to one build or another), but if you do choose to build them both, it's pretty easy to set up in your build project. Just add a second ConfigurationToBuild section.
<ConfigurationToBuild Include="Debug|Any CPU">
<FlavorToBuild>Debug</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
<ConfigurationToBuild Include="Release|Any CPU">
<FlavorToBuild>Release</FlavorToBuild>
<PlatformToBuild>Any CPU</PlatformToBuild>
</ConfigurationToBuild>
I did this for a Release and a Training Build but only get the Release folder created and populated for _PublishedWebsites. The Solution and Project Files support 5 different Builds for 5 different environments. The TFS Build completes successfully with only the Release folder populated.