I'm currently working on integrating the TFS source control system at my work ... I run into one small problem ... I need different version of web.config (among other config files) for different branches (due to the environment that we're releasing the web application to).
(for example - i don't want to merge the web.config file all the time even though there are differences ...)
Is there a good way to keep track of that (instead of manually diff-ing the files)?
thanks!
What I have seen so far is that people write installers that manipulate the settings that are needed. So you don't have to bother with other environments than the development environment. Also because in some companies the people in development aren't allowed knowledge of all the settings in the production environment.
I haven't used it myself but know/knew of people using web.config transformations. That might be an option for you.
Web Deployment: Web.Config Transformation
Visual Studio Web Config Transformations and TFS Build
Related
we are a team who would like to replicate the TFS from one site into another site. Both are in different domain and cannot communicate in any means. Please suggest the best practices of the same.In addition I am also looking for a standalone tool to give me a detailed report of the TFS environment(which includes the work-items, etc) along with the SQL server attached to it. The intention is to replicate the same environment so that a full backup goes through fine.
You want to setup a complete clone of your environment in another site, disconnnected from your. Some key points follows:
You need a proper backup of the current TFS data, see Backup TFS
Size the target environment in terms of disk, memory, network, etc.
Install on the new site a compatible SQL Server version
Install on the new site the same (or newer) TFS version
Study the instruction to Clone TFS and apply them on the new site
Plan for changed environment: Active Directory domain, user accounts
Topology could be different, you have to rebuild you Build and Test infrastructure or, at least, properly remove the old references from the new site
What you are wanting to do is not possible.
You will need to put your TFS server somewhere accessible to both locations. I would recommend either VSO (TFS.visualstudio.com) or a custom IAAS instance and domain.
We have Release Management Update 2 installed and using TFS 2013 Update 2 continuous deployment build template for releasing a web site.
We have three stage types: Integration, Staging and Production.
What's the best way to release a web site when there are web.config transformations for each stage? Transforms are for connection string, appsettings and log4net.
I'm starting to lean toward this question's best answer, yet would like to know if I'm missing a tool or an easier path.
Release Management for Visual Studio 2013 has its own variable management system. When you configure a Component, you get to set what properties are used for it.
You can then use a single web.config file with "__myveriableName__" in place of the values. On the properties tab of the Component you can select what types of files the system will find and replace variable in. So here you would say *.config.
This way you can have just two configs configured... dev.config that you use for local development with local settings and a release.config with the variables defined that Release Management uses...
You can get information on how from Professional Application Lifecycle Management with Visual Studio 2013 or on the Visual Studio site.
I'm trying to set up a TFS server for our small dev team, and since this is fairly new to me I have a couple of questions.
1) We are developing ASP.Net websites for internal use (intranet etc), these websites currently are not saved with visual studio solutions, they get saved basically as they are on the server and we just update them using Visual Studio by doing file > open website.
So my first question is should I save these as solutions in TFS? What would the benefit of this be?
Im coming from a background of developing WPF applications and have always seen everything saved with a solution in TFS.
2) What should we store in our TFS repository (and what should we exclude)?
At the moment I am storing source code & Documentation but is it really appropriate to store things like installers for VS plugins / small applications or should this kind of thing all be placed on a server someplace?
So my first question is should I save these as solutions in TFS? What
Yes, you could create a solution containing the different ASP.NET web applications.
would the benefit of this be?
Your source code will be version controlled
What should we store in our TFS repository
Source code, third party assemblies that your ASP.NET applications might require, script files, basically everything that allow to get your site up and running. Documentation should also be stored along with the project. Same stands for installers (the source code only, not the MSI) if those installers allow to deploy the ASP.NET application on the live servers.
and what should we exclude
Compiled assemblies, but they are automatically excluded by TFS anyway.
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.
I would like to hear the best practices or know how people perform the following task in TFS 2008.
I am intending on using TFS for building and storing web applications projects. Sometimes these projects can contain 100's of files (*.cs, *.acsx etc)
During the lifetime of the website, a small bug will get raised resulting in say a stylesheet change, and a change to default.aspx.cs for example.
On checking in these changes to TFS, and automated build would be triggered (great!), however for deploying the changes to the target production machine, I only need to deploy for example:
style.css
default.asx
MyWebApplications.dll
So my question is, can MSBuild be customized to generate a "code pack" of only the files which require deploying to the production server based on the changeset which cause the re-build?
You are probably going to have a hard time getting MSBuild itself to do this, but the ideal tool to use in your situation is the Web Deployment Tool, aka MSDeploy. With this tool you can tell it to deploy the changes to the target website. It will determine only the changed files and then just deploy those. Also you can perform customization to the deployment and a whole bunch of other stuff. It's a really great tool.