I am managing releases for a team of 8 developers. We have three environments:
DEV - where we all make our changes
UAT - an environment for users to test changes
LIVE - live environment
We use Visual Studio 2015 and TFS 2017.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number). Sometimes different users will make changes to the same files but not all changes should be released.
Once tested in UAT, the changes are released to Live however sometimes a file needs to move from UAT to Live that has earlier changes in it that are not approved for Live release yet.
Please could I ask users' advice as to what the best way for managing this process should be? Unintended changes keep getting released to UAT or Live when they should remain in DEV or UAT.
Any advice would be very welcome. Thanks
Usually this kind of "the best way" question is primarily opinion-based and hard to answer.
Many good questions generate some degree of opinion based on expert
experience, but answers to this question will tend to be almost
entirely based on opinions, rather than facts, references, or specific
expertise.
Developers make changes to files and submit them for release to UAT by emailing a list (sometimes with a changeset number).
For this scenario, instead of using E-Mail to send lists, perhaps you could use this extension
This extension is a build task you can use in build steps. This task generates a markdown release notes file based on a template passed into the tool. Here is an example of release notes output:
Release notes for build SampleSolution.Master
Build Number: 20160229.3 Build started: 29/02/16 15:47:58 Source
Branch: refs/heads/master
Associated work items
Task 60 [Assigned by: Bill ] Design WP8 client Associated change
sets/commits
ID bf9be94e61f71f87cb068353f58e860b982a2b4b Added a template ID
8c3f8f9817606e48f37f8e6d25b5a212230d7a86 Start of the project
The suggestion on the comment is a way that fits your needs and your circumstances. You could create three branches stands for your three environments. And for each branch you could use branch policy(GIT) which will protect your branches and avoid unintended changes merged to UAT and Live.
Since the TFS system or any other tool is hard to judge whether some files are approved or not to release yet. It' based on your team management, you could use permissions in TFS to limit users who have access to deployment or do the release. For example only PM and team leader could handle this. Combine with work items, charts , test management, reports and other functions in TFS.
Note Team Foundation Server is a product that not only provides source code management,build, release, but also reporting, requirements management, project management (for both agile software development and waterfall teams), lab management and testing capabilities. It covers the entire application lifecycle, and enables DevOps capabilities.
Suggest you first go through the Release Management in TFS and also take a look at how to configure your release pipelines for multiple environments deployments
Related
I am looking for a tool to manage the collection of binary files (input components) that make up a software release. This is a software product and we have released multiple versions each year for the last 20 years. The details and types of files may vary, but this is something many software teams need to manage.
What's a Software Release made of?
A mixture of files go into our software releases, including:
Windows executables/binaries (40 DLLs and 30+ EXE files).
Scripts used by the installer to create a database
API assemblies for various platforms (.NET, ActiveX, and Java)
Documentation files (HTML, PDF, CHM)
Source code for example applications
The full collected files for a single version of the release are about 90MB. Most are built from source code, but some are 3rd party.
Manual Process
Long ago we managed this manually.
When starting each new release the files used to build the last release would be copied to a new folder on a shared drive.
The developers would manually add or update files in this folder (hoping nothing was lost or deleted accidentally).
The software installer script would be compiled using the files in this folder to produce a SETUP.EXE (output).
Iterate steps 2 and 3 during validation & testing until release.
Automatic Process
Some years ago we adopted CI (building our binaries nightly or on-demand).
We resorted to putting 3rd party binaries under version control since they usually don't change as often.
Then we automated the process of collecting & updating files for a release based on the CI build outputs. Finally we were able to automate the construction of our SETUP.EXE.
Remaining Gaps
Great so far, but this leaves us with two problems:
Rebuilding Assemblies The CI mostly builds projects when something has changed, but when forced it will re-compile a binary that doesn't have any code change. The output is a fresh build of a binary we've previously tested (hint: should we always trust these are equivalent?).
Latest vs Stable Mostly our CI machine builds the latest versions of each project. In some cases this is ok, but often we want to release an older tested or stable version. To do this we have separate CI projects for the latest and stable builds - this works but is clumsy.
Thanks for your patience if you've got this far :-)
I Still Haven't Found What I'm Looking For
After some time searching for solutions it seems it might be easier to build our own solution, but surely someone else has solved these problems before!?
What we want is a way to store and manage binary files (either outputs from CI, or 3rd party files) such that each is tagged with a version (v1.2.3.4) that allows:
The CI to publish new versions of each binary (but reject rebuilt versions that already exist).
The development team to make a recipe for a software release (kinda like NuGet packages.config) that specifies components to include:
package name
version
path/destination in the release folder
The Automatic package script to use the recipe collect the required files, and compile the install package (e.g. SETUP.EXE).
I am aware of past debates about storing binaries in a VCS. For now I am looking for a better solution. That approach does not appear ideal for long-term ongoing use (e.g. how to prune old binaries)... amongst other issues.
I have tried some artifact repositories currently available. From my investigation these provide a solution for component/artifact storage and version control. However they do not provide tools for managing a list of components/artifacts to include in a software release.
Does anybody out there know of tools for this?
Have you found a way to get your CI infrastructure to address these remaining issues?
If you're using an artifact repository to solve this problem, how do you manage and automate the process?
This is a very broad topic, but it sounds like you want a release management tool (e.g. BuildMaster, developed by my company Inedo), possibly in conjunction with a package management server like ProGet (which you tagged, and is how I discovered this question).
To address some specific questions you have, I'll associate it with a feature that would solve the problem:
A mixture of files go into our software releases, including...
This is handled in BuildMaster with artifacts. This video gives a basic overview of how they are manually added to releases and deployed to a file system: https://inedo.com/support/tutorials/buildmaster/deployments/deploying-a-simple-web-app-to-iis
Of course, once that works to satisfaction, you can automate the import of artifacts from your existing CI tool, create them from a BuildMaster deployment plan itself, pull them from your package server, whatever. Down the line you can also have your CI tool call the BuildMaster release management API to create a release and automatically have it include all the artifacts and components you want (this is what most of our customers do now, i.e. have a build step in TeamCity create a release from a template).
Rebuilding Assemblies ... The output is a fresh build of a binary we've previously tested (hint: should we always trust these are equivalent?)
You can mostly assume they are equivalent functionally, but it's only the times that they are not that problems arise. This is especially true with package managers that do not lock dependencies to specific version numbers (i.e. NuGet, npm). You should be releasing exactly the same binary that was tested in previous environments.
[we want] the development team to make a recipe for a software release (kinda like NuGet packages.config) that specifies components to include:
This is handled with releases. A developer can choose its name, dates, etc., and associate it with a pipeline (i.e. a set of testing stages that the artifacts are deployed to), then can "click the deploy button" and have the automation do all the work.
Releases are grouped by "application", similar to a project in TeamCity. As a more advanced use case, you can use deployables. Deployables are essentially individual components of an application you include in a release; in your case the "Documentation" could be a deployable, and maybe contain an artifact of the .pdf and .docx files. Deployables from other applications (maybe a different team is responsible for them, or whatever) can then be referenced and "included" in a release, or you can reference ones from a past release.
Hopefully that provides some overview and fits your needs. Getting into this space is a bit overwhelming because there are so many terms, technologies, and methodologies, but my advice is to start simple and then slowly build upon it, e.g.:
deploy a single, manually uploaded component through BuildMaster to a share drive, then manually deploy it from there
add a deployment plan that imports the component
add a second plan and associate it with the 2nd stage that takes the uploaded artifact and deploys it to the target, bypassing the need for the share drive
add more deployment plans and associate them with pipeline stages and promote through them all to "close out" a release
add an agent and deploy to that instead of the default localhost server
add more components and segregate their deployment with deployables
add event listeners to email team members at points in the process
start adding approvals if you require gated "sign-offs"
and so on.
Right now I have an Azure PaaS solution with a single repo in TFS - we right-click publish from VS to an App Service and then swap slots to get code to production. Small team, disciplined check-ins (or so I thought), etc.
I made a decision to check code in that wasn’t production ready, thinking if needed, I could roll back and publish a hotfix should the need arise.
Well, the need has arisen and I've rolled things back to apply the fix. This was a bit of a headache though.
I’m a little unclear on what the right thing to do is moving forward. What I want to try is:
Create a branch from our MAIN repo and stick all ongoing development there, call it DEV. We'll create two workspaces on our machines - one for each branch.
When we're ready to push a feature, merge down to MAIN and then QA before right-click publishing > Staging > Prod.
At a high level, does this seem like a step in the right direction?
What I’m trying to do is keep this project/alm lean and simple. I don't want to go as far as introducing a build server with RM and other expensive (time, materials, process) components - I just want a sensible, incremental upgrade in the maturity of our current setup to avoid the above headache and this is all I could come up with.
That's two way for your reference, one base on the working flow , one base on the publish (releaseing)
A. Just using mainline and tagging for release
Pros:
Avoid merge hell.
Keeping to the mainline encourages some best practices like proper
release planning, not introducing a lot of WIP, using branching by
abstraction to deal with out-of-band long term work, and using the
open closed system and configurable features for dealing with
managing works in progress that may; or may not; need to be disabled
now or in the future in order to release or to avoid a full rollback.
Cons:
Dealing with works in progress becomes an issue and adds to potential
surface attack area when it comes time to release. However, if your
developers are disciplined then new features should be configurable
and modular and therefore easily disabled/enabled, or there is no WIP
and at each release point all work is either completed or has not yet
been started (i.e. Scrum).
Large scale/out-of-band changes require more thinking ahead of time
to implement.
B. Branch by release
Pros:
You can begin working on the next iteration while the current
iteration finishes its round of acceptance testing.
Cons:
Tons of branches.
Still need to tag branches at release points.
Still need to deal with WIP and merge WIP from previous release
branch into next release branch if it's not going to make it and
still need to disable or yank it of release branch and re-run
acceptance tests.
Hot fixes need to be applied to more branches (release branch +
hotfix + new tag merge hotfix into vnext branch and possibly
vnextnext depending on where the hotfix fails.)
With respect to your point 1. I would not recommend using two workspaces, since you already are running "two workspaces" internally with two branches. The approach is not that bad, just a litte hard to do in TFVC, meaning the old server based version control inside TFS. I do hope your planning to merge everything from dev to main at point in time.
In general your guide is more matching with Git as source-control, and especially gitflow http://nvie.com/posts/a-successful-git-branching-model/ as a branching model. We are running that with success within my team.
You can migrate from TFVC to git using git-tf http://git-tfs.com/
If you are looking for a cheap model that scales out with buildservers and such I would reccommend looking at Visual studio team services https://www.visualstudio.com/en-us/products/visual-studio-team-services-vs.aspx as well to host and build your code. There you also have Release management integrated without cost(up to 5 people/free for all visual studio subscribers)
I have scoured the internet to find out what I can on this, but have come away short. I need to know two things.
Firstly, is there a best practice for how TFS & Team Build should be used in a Development > Test > Production environment? I currently have my local VS get the latest files. Then I work on them & check them in. This creates a build that then pushes the published files into a location on the test server which IIS references. This creates my test environment. I wonder then what is the best practice for deploying this to a Live environment once testing is complete?
Secondly, off the back of the previous - my web application is connected to a database. So, the test version will point to a test database. But when this is then tested and put live, I will need that process to also make sure that any data connections are changed to the live database.
I am pretty much doing all this from scratch and am learning as I go along.
I'd suggest you to look at Microsoft Release Management since it's the tool that can help you to do exactly the things you mentioned. It can also be integrated with TFS.
In general, release management is:
the process of managing, planning, scheduling and controlling a
software build through different stages and environments; including
testing and deploying software releases.
Specifically, the tool that Microsoft offers would enable you to automate the release process, from development to production, keeping track of what and how everything is done when a particular stage is reached.
There's an MSDN article, Automate deployments with Release Management, that gives a good overview:
Basically, for each release path, you can define your own stages, each one made of a workflow (the so-called deployment sequence) containing the activities you want to perform using pre-defined machines from a pool.
It's possible to insert manual interventions/approvals if necessary, and the whole thing can be triggered automatically once your build is done.
Since you are pretty much in control of the actions performed on each machine in each stage (through the use of built-in or custom actions/components) it is also certainly possible to change configuration files, for example to test different scenarios, etc..
Another image to give you and idea of how it can be done:
We are 5 developers working today with 1 database.
We have always one ASYNC service working in order to allow debugging, it means that when a developer wants to debug async, he announce to the others that he is hijacking the async service to his machine till he finishes the debugging.
We want to switch to a database per developer, there are a lot of issues with that, for example syncing schema changes / solutions with other programmers/
What is the best practice with large team of developers, is there any tool / methodology that is best for large teams.
Also, in general, what is the best practice for large teams developing Dynamic CRM 2011.
Thanks
Typically, I have worked/advised the following:
All devs work on their own virtual system. Much easier debugging. No trampling on or coordinating with others. I use VirtualBox.
Work is exported (unmanaged solutions) into a common build system.
Work is merged into the relevant managed solution(s) in build.
Managed solution(s) exported from build and applied to test / uat / pre-production etc.
Managed solution(s) applied to production environment.
Highly recommended reference: Microsoft released a very thorough whitepaper on Lifecycle management. Read about it here.
A typical development flow could be
Developers develop against their own personal development organization (Online/On-premise), in a solution with the same publisher / name
They export the developer solution
They unpack the zip file into the XML structure
And check it into source control, merging it with the master version
A typical deployment into the integration organization could be
Get a latest version of the XML structure from source control
Package it into a .zip solution
Import it into the integration organization
This way, you have a full history of all changes, linked to the developers, and you can make controlled merges, using merging tools you're familiar with.
A developer can always get a latest version from source control, package it and deploy it in his own development organization.
How do you answer the following questions from managers, testers and other people in your team:
In what build is bug #829 fixed? What tasks have been completed in our current test build?
So simply put, how do you achieve traceability of your requirements, tasks and bugs right from them being reported reporting through to deployment? What processes, tools and techniques are you using to achieve this?
We use TRAC with SVN in our Company and perform daily rolling builds to DEV / STAGING & STABLE environments with regular scheduled deployments (once a month... ish) to a PRODUCTION Environment.
When a bug is reported, it's entered into TRAC and given a Tickets number (e.g. #1001)
When the bug is fixed, the code is checked back into SVN with the ticket number(#1001) in the SVN Checkin notes.
The developer takes a note of the SVN Changeset number (e.g. [5000]) and opens the TRAC web ui. When closing the ticket, they put the changeset number in the notes of the ticket.
This way, the SVN checkin reference the ticket... and the ticket references the SVN Checkin.
Our daily builds are then performed against an SVN Changeset (e.g. todays build is everything up to changeset [5050]) and a note is made of this in our deployment notice.
Deployed On | Environment | Changeset
--------------+-------------------------+--------------------------
10-01-2008 | DEV | 5100
10-01-2008 | STAGING | 5080
10-01-2008 | STABLE | 5050
01-01-2008 | PRODUCTION | 5000
That way the testers when reviewing fixes for testing know by the changeset in the ticket comments if the build they're looking at includes the fix.
We use TFS in conjunction with JetBrains' TeamCity for CI.
When associating check-ins with tasks, our custom check-in policy prepends the associated tasks and bugs with their ID's and titles to the check-in comments.
These comments are then used to generate the release notes, which are automatically generated for each build.
We are tagging the source control check-in with the defect number that has been fixed or the enhancement number that has been implemented.
By retrieving the check-in log between two builds, you can determine what has been implemented or fixed.
We use a managed SVN service called Beanstalk (http://www.beanstalkapp.com/) that allows you to easily tie in with a number of Bug/Feature management systems. In our case, we use Fog Creek's FogBugz for that end of things. SVN/Beanstalk permits you to make notes when you check in a build that will, in turn, affect the status of one or more FogBugz cases.
On the client end, we use Tortoise SVN and Visual SVN to manage the interaction of the local client and the Beanstalk SVN server (Tortoise provides the actual service, Visual SVN provides the integration between Tortoise SVN and MS Visual Studio).
I highly recommend both services and the Tortoise/Visual SVN client.
We are using Fogbugz which has build-in subversion integration. Basically there is a plugin for Fogbugz which checks for SVN check-ins in the background. So if you supply a Fogbugz-case id at your check-in, it gets automatically linked with this check-in.
As far as I know you don't need any special application (like Beanstalk for example).
The other way round is little tricky. In our company there is a convention that for every (future or past) build there is a "release" in Fogbugz. If you fix a bug or implement a feature you assign the case to the right release.
Then it's quite easy to get a list of all implemented features of build X.