We are a small team of 3 developers. We have a mix of classic ASP code and ASPX pages. All the code is contained in one solution with multiple projects. We are currently not using any VC software and have just install TFS 2013 and want to move to using its VC. Our current environment is setup as follows.
Development environment - new code or changes to existing code.
Test Environment - once the code from development passes unit testing, it is moved here to allow users to test changes.
Staging Environment - this is a mirror of production. once the users have accepted the changes in test we migrate the code here to test and make sure it works against the mirror copy of the database(sql).
Production Environment - code is not modified in this environment.
All of this is done manually and now that our staff has grown from 1 to 2 to 3 developers over the last 6 months we need to make use of version control. What we are not sure of is how to implement this same environment using TFSVC. Do we need to install TFS in each environment and have the 4 separate copies of the code and then how do we migrate the code between each environment using TFS. We need help and suggestions on how to set this up. We want to keep it simple since there is only 3 of us.
Normally you would have one TFS server that holds the sources for all of your environments. Many people implement a branching strategy to support different versions of source code deployed as part of different releases or in different staging environments.
Many people treat TFS as a Development Tool and as such it ends up in the development "network". We recommend people to treat TFS as a production server though, it contains your source code (Intellectual property and an large investment in knowledge and tme) and you might also use it to hold your Product Backlog (which could contain sensitive information on where your company wants to move in the future). If you were to lose any of them it would be a great loss. So make sure you treat the TFS server as something holding value and implement a proper backup & restore and disaster recovery procedure.
Helpful links:
ALM Rangers Planning Guide
ALM Rangers Version Control Guide (aka Branching Guide)
Related
We have recently started to use cluster servers in our company. I have done some reading on MS WebDeploy and the technology looks promising. Our requirements:
Create backups before deployment
Deploy to different servers
Test server
Two live clusters
Ability to stop application pools for specific web applications before publish and start them again afterward
Allowing limited access: In other words a developer may only publish to sites that they are responsible for
Possible customisation: We would like to disallow publishes if related bugs have not been solved in our bug tracker, and possibly more, like approvals from management. Can external customisations be done without losing VS integration
Visual Studio integration and the use of Web.config transforms
SQL Schema changes and especially stored procedures without affecting data
Our environment
IIS 7
Windows Server 2008
SQL Server 2005 (Planned move to 2008)
Visual Studio 2010
Based on my research it does seem that many of the above requirements have been met. What I would like to know is how reliable the solution is and whether the above requirements will be met. More importantly I would like to know what your personal experiences with webdeploy are and whether you would recommend it or whether there are better alternatives.
At the moment we are using file copying which proves to be unreliable (due to human error) and tedious.
We do about 80% of what your asking for using WebDeploy packaging and Thoughtworks GO! for orchestration of our release pipeline. It works really well. We have over a 100 websites/services and deploy something to production every four hours. The following post describes how we perform the deployment and links to related information:
http://www.dotnetcatch.com/2016/12/28/zero-downtime-clustered-deployment-of-webdeploy-packages-via-powershell/
One note, config transforms happen at build time which is problematic when you want to deploy to multiple environments. WebDeploy parameterization accomplishes the same result but is applied at deploy time. Check it out -
http://www.dotnetcatch.com/2014/09/08/parameterizationpreview-visual-studio-extension/
I'm interested to find out what would be the good way to make changes to production database and source code in web application (ASP.NET, SQL Server 2008).
A little bit more details, we develop on local machines, and then we need to transfer the code and database changes to production (pretty much standard story).
At the moment we do it in the evening, change the database directly from management studio on production server, and then just overwrite the existing asp.net code (copy/past).
You're talking about Release management. What you're asking about is a big subject with a LOT of different answers. The best solution for you is not something we can tell you. There are trade offs to consider.
For example, what you're describing is a very basic release management process that would be considered an "immature" process.... It does not take into account rollback plans, versioning, separation of concerns, proper testing, or any of a hundred other factors that a "mature" release management process involves.
A mature process is very good, but if you don't have the resources, it's not feasible.
To get to the point, I don't think you question can be answered fully here. I'd suggest starting to research "change management", "release management", "Application Lifecycle management", and "Applicaiton Development Lifecycle". I'll have a few good starter links for you in a minute.
Just a forewarning, though, you are asking a question that's going to open your eyes and your world in ways you probably haven't considered. There are things like automated builds to consider, tools to do it for you (high priced, free, and everything in between)
http://en.wikipedia.org/wiki/Release_management
http://en.wikipedia.org/wiki/Application_lifecycle_management
A few simple options for JUST what you're asking about can be found here:
http://msdn.microsoft.com/en-us/library/7hd4c0x3(VS.80).aspx
Also, since you talked about source code without mentioning which source control you're using, I need to say... if you're not already using source control, you need to. You'll wonder how you ever lived without it once you start using it.
Depends on whether it's the first deployment of a new app, or an update to the app.
For small updates, record all your database changes as sql scripts. You must strictly enforce that all changes to development are applied as sql scripts. Put the scripts in source control. Deploy the update by running the scripts on production.
For new apps you may have thousands of scripts. You can't run them individually. Consolidating them into a master script takes too much time. (although you still want to check EVERY script into source control). In this case you reach a milestone in development then FREEZE the development database, and declare it a baseline. Use the database tools to generate a master script(s). Deploy production by running this script(s). Manually create data scripts for your lookup tables to keep it separate from junk dev data.
Avoid a database copy. Avoid changing by hand through the GUI. Scripts are the way. How you go about collecting the scripts, consolidating to master scripts, generating the scripts, etc is another story.
All,
My dev team and I would like to setup a development environment for our ASP.NET projects. BY development environment i do not mean Visual Studio. I mean, that we have a Database Server, a Application Server and a Web Server in a 'Development Environment'.
We want to use this as our integration environment. Where the developers all work on there parts of ASP.NET Applications and then we can push our new changes up to test them as a whole.
My Question is , what is the best way to deploy our code together without stepping on our toes?
Thanks.
Team Foundation Server is a good candidate for this.
You need a source code control methodology and with it you'll get the benefits you're searching for. SVN and other solutions in this space offer "conflict resolution" to avoid inadvertent overwriting/toe squashing.
Setup a subversion repository, get all of the developers up to speed on svn and using it.
Once you have your source under control you can consider setting up a continuous integration server which can build your code and deploy to your target environment in batch. Organizing your project code properly into trunk, tags and branches per solution will make it very easy to control what is deployed or redeployed to your dev environment at any given time.
There are other options for source code control (git, tfs, and many others) but they all offer close to the same features... SVN is one of the nicer options because it's open source, free and stable.
Another thing to consider is keeping your database schema changes in sync with your code changes. Consider using migrator.net or similar solution to enable your team to keep everything in sync through revisions, including database state.
I work for an agency that has been responsible for maintaining a client’s .net 3.5 website for a number of years along with another agency. Work is farmed out by the client to both agencies on a pretty much ad-hoc basis.
The site is quite old and has a structure and deployment process to match. The site is setup that developers have local copies of the sites. There is a staging environment, where client feedback and approval happens, followed by the live environment. There are a number of scenarios where work from one agency will be on the staging environment awaiting approval, and changes from the other agency need to go through staging, approval and deployed to live without the original changes being affected. Most of the time we get away with it but it’s far from ideal as not all conflicts can be resolved.
Up until recently we had still been on Sourcesafe but have moved over to Subversion and are running into many more scenarios where work is overwritten. This obviously isn’t a fault with subversion, rather that the locking of projects and files in Sourcesafe served as a good indicator to developers from both agencies that someone was working on that project or file. The process previously was that you checked out a file from sourcesafe and kept it checked out until changes went live (acknowledge that this is a rubbish process hence the desire to move away from sourcesafe and such a model)
The trouble is that even though we know that the way we do it now is bad, I’m at a bit of a loss as to how to restructure the overall site and deployment process to make it “better”. Some ideas we’ve pondered are:
Separate dev, test and live branches in subversion so we need to commit and build the appropriate branch before deploying (not really sure how to make that work)
Single repository for both agencies but a separate staging environment for each. Staging environment could then reflect the changes assigned to each agency
A separate instance of the staging site for each branch
Any suggestions of next steps or examples of similar situations and solutions from the SO community would be greatly appreciated!
Thanks
Joel
I would recomend:
Use git, its really very good for working out how to merge changes.
Have seperate staging enviroments for each company, then, once changes are approved, merge (carfully) into a final staging environmet that only exists to help sort our merging issues there, then push to live.
Also make sure both agencies know who's working on what and try to wait for the other agency to finish working on part X of the app until the other has finished, in the end this is the best solution, a little bit of comunication.
We have been a ColdFusion shop for 10 years, and are now switching over to ASP.net MVC. Our target framework is .net 4.0 BETA 2 using VS 2010 BETA 2. We set up two instances of Windows Server 2008 (staging and production), and will be using our existing database server (SQL Server 2008).
None of us really have much experience in ASP.net itself, though we are all very comfortable in C# and the MVC pattern. The coding itself isn't much of an issue; but the deployment process is. Our goal is to be able to have a CI setup that will automatically pull down, and test, our applications into staging on commit - then have the option to tag, then switch, the checkouts on our production sites when websites pass QA.
Some of the things I'm having issues with here is the concept of an ASP.net application and how it integrates into SVN. CF, like PHP or RoR, are all scripting languages and as such require no build process (checking out the source into production is very straightforward). But in this case, applications need to be compiled - which is where we start to have problems. Will we need to create another server (or use an existing one) that has some sort of application that pulls down code, compiles it, then somehow pushes it on the live servers? If so, what is considered the best way to accomplish this? I imagine if we end up using a build tool such as Nant, adding additional steps to migrate the database would be trivial, but what is the best way to accomplish this as well?
Another, slightly unrelated, problem is how our designers will work with our code. Most of them are on Macs, and using VS isn't much of an option. How will they be able to edit the aspx, css and image files easily? Our goal is to make this as transparent as possible to them.
We have done a lot of shopping around, and ASP.net MVC seems to be the best option as far as our familiarity with the language, and our current platform. We just need to figure out a good build process so everything is as transparent as possible. I understand there are a ton of resources available on this, but I wanted to get the opinions of the people here from first-hand experience.
Microsoft TFS has a wonderful build solution built-in. It's costly, but effective. In addition, you cannot lose by looking at CruiseControl, which is free. TeamCity from JetBrains is also a great option. All of these Continuous Build and Integration solutions would provide a good starting point for your research.
http://msdn.microsoft.com/en-us/teamsystem/dd408382.aspx
http://www.cruisecontrol.com/
http://www.jetbrains.com/teamcity/
Even Draco.net is a good consideration:
http://draconet.sourceforge.net/
We use http://www.cruisecontrol.com/ (CC) running on our SVN / Build server. You can configure CC via it's own config/script files to pull down the latest source from SVN and then spawn one or more Nant or MSBuild scripts which can perform your build and deployment.
We script all of our database changes into change scripts which also go into SVN. We then have a custom command line tool which will deploy the change scripts to SQL Server during the web site deployment. All of that is done in the Nant script.
So each project's Nant script handles the build, web site deployment and SQL change script deployment.
The tricky part is handling rollbacks if/when something goes horribly wrong. I would suggest posting another question for that specific problem.