As most companies have, we have multiple environments and multiple build pipelines in Team Foundation Server (TFS) which are doing automated tests, builds, Nuget package publishes, ….
We are maintaining a Nuget package for local use, and I’ve come across a problem and wanted some advice from this community, hopefully I can get any good answers.
Let’s say, we have:
3 environments: Development -> Integration -> Production.
1 Nuget repository where we publish Nuget packages from our Integration environment.
If we increment the Nuget package from 1.0.0 to 1.0.1: that new version is published to the repository only during the Integration Build Pipeline.
It’s not a problem to reference the new version 1.0.1 when I’m working on my machine because I can generate that new package locally.
The problem occurs during the Development Build Pipeline: it won’t find the new version 1.0.1 in the Nuget repository yet because the Integration Build hasn’t occurred yet. Then the build step throws an exception about the version not present in the Nuget repository.
We don’t want to publish the package from Development environment, because those builds are in ‘Debug’ mode while integration environment is building in ‘Release’ mode.
Are there any suggestions or best practices on how we should take care of this?
Huge thanks for any insights.
We use TFS 2018 the old way, without yaml files.
Related
What is the process for upgrading the default tasks loaded by Microsoft in an on-premises TFS with no internet connectivity?
According to https://learn.microsoft.com/en-us/vsts/build-release/tasks/ there are several tasks now available and supported in TFS v2015-2018/VSTS that do not appear in my TFS 2017u2 installation (specifically the Download Secure File task).
The default tasks are not shown in the Manage Extension screens and the git repo (https://github.com/Microsoft/vsts-tasks) does not appear to have any instructions for how to package and install the latest versions in an existing TFS.
Download Secure File this task is not support by TFS2017 update2 for now.
In the right of the task, there is a column called Versions which stands for the supported TFS version and VSTS for now.
I use TFS on-premises and I don't see some of these features. Why not?
Some of these features are available only on VSTS and not yet
available on-premises. Some features are available on-premises if
you have upgraded to the latest version of TFS.
Source Link
The task you need is only available/build-in with VSTS by now.
However, this task is open sourced, you could find it here. You could also build it and package it as normal extension. Take a look at below steps for your reference:
Globally install typescript and tfx-cli (to package VSTS
extensions): npm install -g typescript tfx-cli
From the suitable of the repo run npm install. This will pull down
the necessary modules for the tasks and for the build tools.
Run npm run build to compile the build tasks or build a specific
task (recommended): node make.js build --task ShellScript
Run npm run package -- --version <version> to create the .vsix
extension packages (supports multiple environments) that includes
the build tasks.
With the .vsix files, you are easy to directly upload the extension. Details about this area, you could refer here:
How do you install extension vsix files to TFS 2015 (Update 3)?
How do I use the tfs-cli (tfx) to update a TFS extension for an on-premise TFS instance?
Besides, even you have published the extension to your TFS successfully, this task may not compatible with your present version, just Giulio said, you could create a test first. Certainly, you could also create your own extension as your demands.
Look at the Contribute page: it is a bit cryptic if you are not familiar with Javascript tooling.
CAVEAT: there is no guarantee that an update Task works with your TFS version and rolling back a change is a non-trivial task. Use, at least, a separate Collection to test changes.
I was wondering if there is a way to create one nuget package for multiple version of an assembly (i.e. dll v1.0.0 and dll v1.0.1), so that each version will show in the version drop down option in nuget? Or will I have to create separate packages for each version?(which is what I've have so far)
Thank you
How to set up nuget versions for multiple environment. Guess the nuget versions in your question stands for the package version not the version of nuget.exe such 3.3, 3.5 , 4.0. If it stands for nuget.exe version, have no idea why you need to use different nuget.exe versions for multiple environment.
You could version the packages as you need. A way to cross multiple environments is setting up 3 different NuGet repositories such as:
Development repository: A file share that all developers have read-only access to. The file share has a space for NuGet packages
and one for the matching NuGet symbol packages. Only the build server
(and the build engineers) have write access to this repository.
QA repository: Another file share similar to the Development repository.
Production repository: A private instance of the Klondike NuGet server which serves as the NuGet and symbol server for all NuGet
packages (and their sources) which are allowed to be used in
production builds.
More details please refer this similar question: NuGet Server for multiple enviornments?
I am having trouble understanding the fundamentals of octopus deployment. I am using octo.exe with the create-release and deploy-release commands. I am also using the octopack plugin.
I am getting an error but that's not really the point - I want to understand how these peices fit together. I have searched and searched on this topic but every article seems to assume the reader has a ton of background info on octopus and automated deployment already, which I do not.
My question is: what is the difference between using octopack by passing the octopack argument to msbuild and simply creating a release using octo.exe? Do I need to do both, or will one or the other suffice? If both are needed, what do each of them do exactly?
Release and deployment as defined in the Octopus Deploy Documentation:
...a project is like a recipe that describes the steps (instructions) and variables (ingredients) required to deploy your apps and services. A release captures all the project and package details so it be deployed over and over in a safe and repeatable way. A deployment is the execution of the steps to deploy a release to an environment.
OctoPack is
...the easiest way to package .NET applications from your continuous integration/automated build process is to use OctoPack.
It is easy to use, but as Alex already mentioned, you could also use nuget.exe to create the package.
Octo.exe
is a command line tool that builds on top of the Octopus Deploy REST API.
It allows you to do much of the things you'd normally do through the Octopus Deploy web interface.
So, OctoPack and octo.exe serve a different purpose. You can't create a release with OctoPack and octo.exe is not for creating packages.
Octopack is there to NuGet package the project. It has some additional properties to help with pushing a package onto the NuGet feed, etc.
octo.exe is used to automate the creation of releases on the Octopus server and optionally deploy.
Note: a release in Octopus is basically a set of instructions on how to make the deployment. It includes the snapshot of variables and steps, references to the versions of the NuGet packages, etc.
octopack is a good starter, however I stopped using it some time ago with a few reasons.
No support for .Net 2.0 projects (and I needed to move all legacy apps into Octopus)
didn't like it modifying the project files (personal preference)
Pure nuget.exe was not much more work for me.
Using csx scripts in Azure Functions I can use the Project.json file to install nuget packages, but when I'm using fsx scripts the packages aren't installed (the log console never shows the Starting NuGet restore message). The only way I found is installing locally and uploading the dependencies. Am I missing something?
I think that the current execution model for F# in Azure functions does not support project.json. There is a work in progress PR to improve F# support that will enable this.
For now, I think there are two options:
Install the packages locally and upload them to Azure (as you are doing)
If you're deploying via git, then I think the deployment lets you run deployment script (in the same way in which Azure WebSites let you run a deployment script).
I have not tested the second approach with Azure functions, but I think it could work. For example, see the F# Snippets' deployment script which calls a build script that starts by using Paket to restore dependencies. This way, you need just paket.bootstrapper.exe and paket.dependencies with paket.lock to specify your NuGet dependencies.
I am trying to do a full CI-CD cycle using TFSonline.
when I go with 'AzureWebsite' along with Visual Studio Online, it provides me with a build definition using 'tfvccontinuousdeploymentTemplate.12.xaml'.
On check-in I get the output, the build triggers and deployment also happens to the azure website. The log contains build along with my deployment details, which is also reflected on the TFS portal
When I go the conventional iis route, I tried 2 steps
With Default build template and the good old ms build arguments /p:DeployOnBuild=true /p:VisualStudioVersion=12.0 /p:PublishProfile="dasd.pubxml" this does the build and deploy but I don't get the 'deployment summary', which is to be expected, because i did it via ms deploy...
I used the tfvccontinuousdeploymentTemplate and provided the build settings as the publish xml... well... build happens but the deployment does not
I'd like the build to contain the deployment summary for my deployment.
TFS Online has since been replaced by Visual Studio Online and since by Visual Studio Team Services. The XAML based build engine has been marked for deprecation and will be removed from Team Services in the near future.
The hosted build controller has since been upgraded with build templates for Visual Studio 14, upgrading to the latest tfvccontinuousdeploymentTemplate.14.xaml may also sole your issue until the XAML build engine is removed.
The new Build Engine ships with a "Deploy to IIS" task and there is a 3rd party MSDeployAllTheThings extension which makes it very easy to pick up packaged Web projects.
Your solution to switch to InRelease has since also been replaced by 2 different versions of Release Management and the latest release management feature uses the same tasks as the new build engine uses. So it's able to use the same Deploy to IIS and MSDeployAllTheThings task.
Due to the fact that this question is related to a SaaS solution, the old options are no longer available or will soon be removed.