I'd like to automatically increment my assembly versions based on this ruleset:
Revision is always 0
Build is incremented when the only WIT in the release is a Bug fix
Minor is incremented when the release contains any WIT other than a Bug fix; Build is then always set to 0
Major is never automatically incremented
Naturally this will require a build step that can interact in some way with the project.
My first thought was to build a small Windows Service that utilizes the TFS SDK to construct the version number based on these rules and return it via a WCF call, etc. But I run into a problem there with a business requirement that all code and functionality must be replicated into a VSTS project as well (the customer owns the code and must be able to proceed without me). There's no installing such a service there, of course.
I then considered installing the service on his server, in turn making it available to VSTS. This would pass the Rube Goldberg test with flying colors.
Is there an easier way of accomplishing this task? One that can work in both environments?
EDIT
I found this, but it's doubtful that the TFS SDK is registered in the GAC for VSTS.
Can someone confirm? Is the TFS SDK available to build scripts running on VSTS?
Well now that didn't take long.
I found this and this for using PowerShell to query the REST API. No GAC/SDK needed.
-- EDIT -----------------
I've intentionally excluded content from the pages behind these links as the solutions provided are exceedingly complex; it's not possible to cover the concepts here in a single post. In case the pages disappear or the URLs change, here are the links at archive.org:
1. PowerShell and vNext Builds
2. VSTS/TFS REST API: The basics and working with builds and releases
In any case, the concept is popular and well-covered—in the event these two become inaccessible, there are many others available on the same subject matter. As quickly as I found these, someone could find more.
Related
I am interested in any information about or experiences with deploying PowerApps solutions to new environments within the same tenant.
In my solution I have a canvas-app and several flows between the app and sharepoint. I have used connection references to all connections (sharepoint, mail, etc.). On the devops side I have a build pipeline from my development environment, very much in line with Microsoft's recommendations for ALM. In addition, I have a release pipeline to publish the solution in another environment, e.g. a test environment. I can publish the release but when I access the solution in the new environment all flows have been turned off and all connections to sharepoint have been severed. When I inspect the flows it throws an error that it was unable to locate the connection Id. What strikes me as odd here is that the connection references that are visible in the new solution cannot be selected. However, what I can do is to add a new connection (from each flow), whereafter I can turn the flow back on and activate each of them in the canvas app.
What I am asking for here, is any documentation, guide, tutorial, help, etc. to make this release a little more automatic, so I won't have to re-add connections for every single action from each of my flows.
I think you are in luck 😊 and you should check out the latest PA community call. I think the last demo is the thing you are looking for (especially from that moment I suppose🤔) and is now one of the targets in Power Platform.
If you are considering to introduce source control as well (like git), currently there is a cool experiment going on in the community in that direction which I think is quite promising and you may check this article. But please consider this pack/unpack tool as an experiment and don't just remove the original .msapp files yet 😉.
I think I have finally found a working solution. I'll document my steps here for other ALM hopefuls.
When pushing to the target environment for the first time I need to click on each of the connection references, click on solutions layers, ) use the breadcrumb path to go one step back ] and from here I can assign the correct connection. Subsequent deployments now work without any hassle.
Also, first time deployment, I have learned cannot activate workflows. However, future deployments can activate workflows by managing the setting the the Import Solution build tool
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
I'm starting to dive into TFS 2012 and I have a basic understanding of the tiers and how build servers, controllers and agents work and how different build scripts can have different configurations and projects.
However, one of the things I'm struggling with is a requirement for our source control solution that says that I need to be able to prove a particular changeset or shelfset produced a particular build. That is, given a particular binary, I can point to a release changeset that generated that binary. I should also be able to point to the test changeset that was merged into the release branch. The idea here is not just a separation of duty, but validating that because the release and test changesets are identical, no code was injected into a project by a code reviewer.
I've read one blog post that talks about "Binary promotions" -- would that concept be useful in my situation? I'm having a hard time finding how this binary promotion is set up in TFS.
Deployment
Out of the box TFS doesn't really support deployments, it can deploy to 1 location on build which often is a test server (think lab management). TFS 2012 has built in support for Azure deployments, but they still happen at the end of a build and the build artifacts cannot be automatically deployed to a new location.
You could modify the build template to allow to release to different locations, but that would still be a fresh build for every environment and not true binary promotions.
TFS does, however, have a concept of build quality and actually fires off events when this quality is changed. TFS Deployer is a 3rd party tool that hooks into the quality change event and can execute powershell scripts. This means with a simple change of a dropdown value you can automatically kickoff a script that releases to any environment you want. You can customize the build quality list (per team collection) to be a list of environments (dev, uat, staging, production etc) which the script then figures out where to release the specific build to.
VS2012 also has some nice improvements to web deploy which means deployment configurations are stored in source control with the project, which in theory means they'll be available in the drop folder for TFS Deployer to make use of.
I don't believe TFS keeps a history of build qualities, which means you can't really use the build quality history to maintain a list of what is deployed to which environment. You could fairly easily record this information as part of the deployment script though. Or at the very least add a custom summary node to the build with information about the release.
TFS2012 does have the ability to mark a build as deployed as part of the Azure deployment functionality, you mark tfs deployer builds as deployed using a script but it doesn't feel very useful.
Octopus Deploy is another project that's worth checking out, and could be used instead of TFS Deployer if your build template creates NuGet packages. It requires a bit more control over the production hardware as you need to install agents on each environment to handle releases, but it solves a lot of other issues with deployment.
Versioning
Once you have a nice consistent way of automatically releasing that people don't bypass, you can look at enhancing the build template to inject the build version, or changeset number as the assembly version for anything built as part of that automated build. There's a number of different ways to do it and plenty of blog posts and tools to help you achieve that.
Alternatively you could just use automatic assembly versioning ([assembly: AssemblyVersion("1.0.*")]) to give you the date/time the build occurred, which ends up like 1.0.1234.123 where 1234 is something like the days since jan 1st 2000, and 123 is the minutes since midnight (my specifics may be wrong here).
If you're deploying websites, then I highly recommend injecting the current build version into the html somewhere. This way you can check what version a website is running without needing access to the bin directory. It can also be appended as a querystring to css/js file imports to ensure no browser caching occurs between versions.
Thoughts
Personally I'm hoping Microsoft realise that the xaml build workflows are trying to do too much and that they split the different concerns (build, test, deployment...) into different scriptable parts. Of course that would not be until the next major release of TFS which is years away. Although with Team Foundation Service they are trying to iterate a lot quicker, so they may actually extend the Azure deployment stuff into something more useful in the nearer future.
I apologize for the length of this post but I needed to include a lot of information for proper answers. I hope this does not discourage responses...
Our shop historically has coded web sites using Classic ASP with some newer ASP.NET sites configured as web sites. As everyone knows this means that the source files (*.asp, *.aspx, and *.aspx.vb (or *.aspx.cs)) files are deployed to development and production servers as is.
The configuration management process was (and still is) entirely manual and includes the following steps (requirements):
Taking copies of the modified files and storing them in a "release" folder for archiving.
Taking copies of the production files that will be replaced and storing them in a "archive" folder for easier rollback.
Generating a diff report of before and after source files for code review or general reference when diagnosing a post-release issue.
The developer who coded the changes is not the person who performs the production release. The original developer is required to hand off the source files to another developer for some additional testing and production deployment.
To make the situation more difficult (not with the above..but with what I talk about below) we do not follow a formal release schedule. As individual bugs or enhancements are completed they are released. This means we could easily be making several releases to a site a week. It is even possible that a given site gets two different releases to individual pages on the same day!
Since I came on board I have been trying to transition the team to newer technologies like ASP.NET web applications and ASP.NET MVC. (We have also taken on responsibility for stand-alone applications and console utilities used for non-web processes...so my dilemma still applies.)
The difference between these technologies and the legacy technologies is the pre-compiling. Instead of deploying the code-behind files (*.aspx.vb (or *.aspx.cs)) a dll or exe gets deployed. This type of deployment package has raised several questions (issues ??).
Generating difference reports when the source has been compiled. While the newly modified source files are sitting on the developers system the production copy is a compiled copy.
Making sure that changes related to other bugs or enhancements are not included in the particular release. This would apply to both the original developer and the person performing the release.
Allowing the original developer to pass along the changed files to another developer for build, testing, and deployment.
Up to now I was the only developer on the team working on these types of sites and applications so the conflicts and issues mentioned above where non-existent. (I skip the difference report step and the I do my own deployments.) However, I am trying to push the rest of the team to embrace this plus allow for better distribution of bugs and enhancement tasks.
We are currently using VSS but I am pushing (and will most likely succeed) in getting us moved over to TFS. Some ideas I have are
Setting up a separate build system for use by the developer to do the deployment. This will solve two problems -- (1) Different versions/patches of Visual Studio and other libraries between developers and (2) instances where the person performing the release has checked out files locally for another change. (Of course this does not guarantee differences between the build system and the original developer but at least that means the release is from a consistent config.
Using labels to tag just the modified files. My problem is that while I can identify (and pull down for a build) the modified files, how do I identify the files that need to be included in the build but have not changed. Again, the idea is to not included checked in files that are related to un-released changes.
Using labels to tag all the files for the release (the modified files and the unchanged files). My problem with this is similar to the last one...how do I make sure that a file checked in by another developer (say they went on vacation) for an un-related change is not labelled and included in this build.
Using the labels I could probably write a script to generate difference reports for the labeled version and the previously labeled version. If the process works properly that should result in exactly what changes are included in the the particular release..?
Any other ideas, concerns, points of interest? While I do have some flexibility of the process some of the requirements (like difference report or some way to easily view differences and having separate developer/deployer) are most likely untouchable.
Thank you so much for any help you can provide on this.
To keep track of different versions of the code and to help you manage very fast release cycles (daily) vs long term enhancements you can use branches in TFS.
There is a ton of information out there on branching, but in general I like to try to keep things simple. For example, have one branch called "release" and another "development". Everybody works on the development branch but the code to be deployed to production is merged into the release branch right before release.
This blog post describes the process:
http://team-foundation-server.blogspot.com/2008/01/how-we-branch-our-code-in-tfs.html
Well, based on my experience with VS2003 vs VS2010 for example is that the project structures are different and allowing VS to do a conversion often times results in a solution that either requires a lot of refactoring or is unusable. Having said that; if you can transition everything over to TFS2010 then one way to handle it is to setup different projects for each solution and use the TFS built in version handling for the different releases. You can also set up a build server and schedule nightly builds. If the build is ok then you can push this version into testing and ultimately production. You should really read up on TFS because it's totally different from VSS and is definitely a huge upgrade in allowing you to do team-focused development.
P.S. TFS has a really good Sharepoint integration which will help you and your team keep track of all the bugs and tasks.
We have an automated build and QA process for our software, using tfs/teambuild and msbuild, and we want to be able to know (for audit purposes) whether a component has gone through that process or not.
For example, if a library is installed on a user's machine, I'd like to be able to inspect it in some way to tell that it went through the build. In particular, I want to be able to distinguish it from components built directly on a developer's machine, and then manually installed.
What is the best way to do this? Code signing as part of the build process seems closest to these requirements, but presumably this would not cover any 3rd-party libraries that might be used? I also read about the ILMerge tool to merge all assemblies into one, but then I don't know enough to work out whether they can then be signed or not?
I'm sure we're not the first people to have the requirement, so casting around for any ideas or hints from others who might have done such a thing
Thanks!
Our developer builds are set to keep the versions at "0.0.0.0", but our build server marks the build based on a pre-configured version and automagically generated build string. "1.0.3.xxx". Your build server doesn't allow for this?
Your build process should be updating each of your projects assemblyinfo.cs files (or a global linked equivalent), you can do this with the TFS changeset number, so like the previous poster indicated you end up with the property on each dll of 1.0.changeset.buildno or something similar. You can do this easily in msbuild.
You could have the values of each assembly info file set in source control to be something obvious like 0 or 999.
A lot of what your asking is about process and training as well though.
If your using installers or zips to package your deliverables then you can also label them with the build number as part of your build process.
But if you have changeset you have the link from dll to code, so traceable, coupled with links to third party dll references as defined in each csproj.