We just started using TFS, what's happening is that when a developer modify a code file TFS updates it automatically, but when i go to development server to move files from Development server, files dates are not updated. Is there any easier way of moving files from TFS to staging and production ? or may be any easier way that TFS can update development server automatically?
Why don't you use MSDeploy to deploy your web application throught the different servers?
http://msdn.microsoft.com/en-us/library/dd465322.aspx
Related
Need some advice on the best way to go about this. I've finished my project and need to submit it for grading. This means it will need to be installed on the graders machine and will need to include the Access database that it's linked to.
What's the best way to do this?
You can deploy an MS Access database with ClickOnce.
MSDN Accessing Local and Remote Data in ClickOnce Applications
ClickOnce deployment of Access database
Can i use clickOnce to deploy MS Access database?
At my company we are currently using TFS 2010 which has installed on-premise and we are developing application on it that it is contiouusly being deployed on Microsoft Azure platform.
Our plan is to upgrade our TFS 2010 to version TFS 2015 and host it on a VM on our Azure subscription since this will ease our continuous deployment speed very much by removing network latency, in addition we will be able to use TFS new features.
Question I have is,
What do we have to do to move all TFS project work items, user stories and source code to successfully finish this move and upgrade process.
Before you give your answers, please take into account that we also want to create a local users on new TFS server and map domain users which they are created on the company's active directory server, on Azure VM and during TFS movement we would like to be able to show moved changesets, workitems... everything have been created in TFS database with the newly created local users on the Azure VM.
Firstly, please have a check on this blog for the details on how to do migration upgrade for TFS: http://blogs.msdn.com/b/tfssetup/archive/2013/12/19/migration-upgrade-from-tfs-2012-to-tfs-2013-with-reporting-and-sharepoint.aspx (This blog is about how to upgrade from TFS2012 to TFS2013, it applies to TFS2010 to TFS2015 as well)
Then after the TFS server is moved/upgraded successfully, create a user on Azure.
We are developing a small application that needs to have a local database installed on each users computer that will then sync up to the main database, via web services etc...
Anyways when we deploy the application on the users computer we want to use clickonce deployment. Now I have used this before but not attaching a SQL Server database. I know you can go to prerequisites in clickonce properties and click SQL Server Express.
Now the question is, when you have created your .mdf database file including stored procedures and all - how do you get this attached and setup automatically in the local database that is just installed through clickonce?
Also once this is finished in the future we may want to run updates to the database on the clients machines. We would like to use clickonce for this to publish database updates. Obviously we don't want to overwrite the database and just publish the latest updates based on if they already have the database or not and what version they have.
How could this be achieved using clickonce? Thanks
Does anyone have any advice or techniques for deploying SSIS packages to the Integration services database.
Basically I maintain a number of SSIS packages that need to get deployed to several environments (dev, test and production), there is a need to change the individual database connections as well.
I would like to automate the process of deploying them to these environments, so it can be included in a full application deployment that can be done by the server admins.
I came up with a method for configuring packages for different environments using a single SQL Server configuration table (assuming all environments can connect to the configuration server).
http://www.sqlservercentral.com/articles/SSIS/66426/
If we have 3 developers working on the same Biztalk project what is the best way to set up our development environment?
We are using TFS to store the Biztalk project.
Should we use 1 sql server and 1 Biztalk server and then have 1 or more developer machines that access the sql and biztalk servers? The issue we get with this is when 1 developer compiles and deploys their changes it can effect other developers if they are also trying to compile and deploy their work.
Should we have each developer host their own complete sql and biztalk server for local development either on their machine or within their own virtual machine? The problem we find with this is that each developer could modify their server settings and those settings are not stored in source control. This can cause confusion when changes are deployed to a testing server. Another smaller issue is that each developer would need to have sql server, biztalk server and windows server installed.
Is there another way to set up a multiple developer biztalk development environment?
You will always want to have each developer have a complete BizTalk installation on their own machines. Believe me, it doesn't work otherwise, as you'll just keep getting on each other while trying to deploy/test/debug changes.
That said, you will also want a centralized dev/test environment where you deploy your code for more complete integrated testing and making sure all the changes from everyone are seen together.
Your point about configuration is true, but only up to a point. This is because you should make your solution configuration part of your source code and keep it in source control as well. This is particularly important once you're a bit ahead in your development as you'll need to start maintaining multiple versions of your binding files for each environment (dev, test, production and so on).
tomasr is right. Also, if you have decent hardware and lots of RAM, you may want to setup a VM image of your full developer environment, then share this will all your team. Not as fast as native hardware, but does allow you to roll back changes, replace your VM if you really mess up and everyone then has the same environment – ideally close to the target one.
Setting up a continuous build server is also a most, if your projects are small, you can get each checkin to cause a full build, BizTalk deploy, export of MSI and then run tests. Later as your solutions get more numerous you might have to move to a continuous build of C# changes only, then say nightly or several times a day, you do a full. We have done this with CruiseControl.net, Nant, nunit and various power shell scripts, it was pretty time consuming, but each morning we come to work to find a fully compiled, deployed, exported and tested set of BizTalk solutions ready for the test team.