We have a web application and occasionally a bug will creep up that needs to be taken care of and fixed. We are using subversion as our code repository. What I am wrestling with is at what point do you create a new branch or tag. We were thinking that if the application needed to be rebuilt or the MSI needed to be rebuilt then we would create a branch. In the case of something simple like a typo, we would just distribute out the offending .aspx page.
What are some of your strategies for branching and building strategies?
Currently, ours looks like this. We have a class library, and Web application. We make our corrections, copy over the changed pages/DLLs to the MSI Creator (Advanced Installer) then rebuild our MSI. We are debating on whether or not to use a web deployment project/MSbuild or something similar. We need it to be reproducible, reliable and simple.
When you release your code, you would "tag" it. Let's say you tag it with "ReleaseVersion_1.2.3.4"
The "trunk" would be your main branch. And you continue to develop there.
If a bug comes along for a customer who has the released code, you would branch from the "tag" ( "ReleaseVersion_1.2.3.4" ), and would hotfix something there.
Then you would most likely merge code from this HotFix back to "trunk".
That's the simplest way.
There are many options for branch strategies.
But if your code hotfixes are occasional, this one will work.
Related
My team uses TFS for source control and continuous integration. I'd like to come up with a nice, clean way to show release notes to end users each time we deploy. I'm curious what others are doing to manage release notes in an ASP.NET / TFS environment.
I put together a basic release notes report (for TFS2008) that you may find useful. Not sure if it's what you're after, but it works fairly well for me. You can always take it and do what you want with it to make it more suited to your environment and neds.
Well I typically hold documents like that as part of the solution under source control, so that the document is versioned and tracked. From then on there are several options - one is to bundle it with the release (attach a link to the file to one of the projects and select "Copy Local" = true), or to embed it into one of the projects and use it in a popup - this can be done with the installer project or as part of the "About" dialog. Or do both.
So, I have an asp.net mvc app that is being worked on by multiple developers in differing capacities. This is our first time working on a mvc app and my first time working with .NET. Our app does not have a lot of unit tests in it...
The problem we are having is trying to keep each other from overwriting each others changes. For example:
Two developers are both working on the app and Jon (not his real name) makes a change to a controller, compiles a new dll, and checks in his stuff (both the controller and the dll.) Our svn system automatically updates our DEV server with the changes that Jon just made.
Clyde (also not a real name) also makes a change right about the same time but did not update the code with Jon's change and commits a new dll thereby "forgetting" about Jon's change.
This happens a lot. The question I'm asking is more of a workflow question - how do we solve this issue? Is it just a matter of Clyde needing to be more careful? Can anybody recommend a decent process for us to use?
You don't check in the DLL's. Exclude the bin folder from Subversion in its entirety. It's the .cs files that matter and that will be compiled locally on every computer that checks out the code from Subversion. If your deployment script don't compile the code but is just a simple xcopy statement, you need to either introduce csc to the script or implement a continuous integration system like TeamCity.
The issue you describe is already handled by subversion. When Clyde tries to commit his changes subversion will detect the conflict and offer him the possibility to merge his changes.
This is exactly the scenario that Subversion and other version control systems are designed to avoid. When Clyde checks in, he should get an "out-of-date" error and his commit should fail, thereby forcing him to update his working copy and get Jon's changes before he can commit his own.
Check out the SVN video tutorials from dime casts. These show you best practices like how to setup your project, and how to do the "check in dance" which will avoid the situation you ran into/
http://www.dimecasts.net/Casts/ByTag/SVN
I've used Subersion and .NET application together. Basically what we learned was that you should always do an update to your working copy before making a checkin. That way, any changes made by other developers will be brought down to your working copy and any merge conflicts will be quickly known to you. You can then fix the merge conflicts, checkin and continue to work. If your second developer then updates their working code, the first developers merged code will be brought down and the process will be repeated.
Hope this helps.
ignore the folders bin and obj, but we have bin and Bin.
use svn:ignore
[bB]in
[oO]bj
*.suo
In my line of work I'm often retrieving very specific versions of crusty ASP.NET web apps from their long-forgotten repositories, making minor changes and then recompiling.
A major annoyance in this process is having to create a virtual directory for every web project that I need to recompile. I don't have any problems with the process, but it's tedious and still a very manual process on .NET 1 projects.
Is there a fairly simple way to recompile the binaries of the csproj without setting up a new virtual directory?
Edit: I don't mind using command line tools, or external solutions, as long as they're fairly simple and straightforward.
I'm not sure there's any other way unless you can convert the project to vs 2005.
I ran into a similar issue when i was dealing with a web project that i needed to manage a few branches that all wanted the same virtual directory. I wrote this small app that does some switching of the virtual for you automagically.
I have added on to the app to make it more functional (supporting more than just one project at once)... and i'm sorry to say i have never update the code on the blog. This might just serve as a good starting place for you to manage your virtual directories.
I will try to get the latest code up on the blog soon and i will update this post when i do.
but in the meantime check out the source here
ps. i know this version of the code needs to be cleaned up this version was just a proof of concept.
Here's our problem, we are a Flex shop that uses .NET for the server side logic. We use subversion for our source control and subeclipse in Flex Builder but are still quite new to using source control let alone subversion. Branching and merging seems to work very well on the .NET side but we are running into issues on the Flex side because of the final swf being built on our local machine.
The question is, what does a usual workflow look like for working with Flex and SVN? Particularly, how do you branch and where do you build?
Personally, I keep the Flash/Flex source code in a separate SVN repository that is away from what is deployed to any sort of web server. That way I can create branches and tags specifically for my Flash/Flex application. I also tend to publish any SWF's directly into my local copy of the deployment repository. It does not make sense to me to keep a published SWF under version control unless its part of the what is deployed to the server. I don't like to keep committing an SWF into my Flash source code repository because it takes up unnecessary space and all the source code should represent the latest version, not the resulting SWF.
You'd probably want to branch your project alongside your .Net project so your flex releases are consistent with your server logic.
We use a directory structure like this
+server-side-app
--trunk
--tags
--branches
+flex-client-app
--trunk
--tags
--branches
I would recommend something like that for yourself.
I agree with Matt W. At AKQA we have svn locations four our source and assets. We set up an svn ignore for the bin folders of a project. That way we aren't checking any swfs which means when we update we don't get someone elses swfs or output files.
A good bet is to look into continuous integration with something like cruise control. We build our output on the server which generates all of the files into one location on the server. There are loads of other benefits of continous integration and it's well worth having
What are the strategies for versioning of a web application/ website?
I notice that here in the Beta there is an svn revision number in the footer and that's ideal for an application that uses svn over one repository. But what if you use externals or a different source control application that versions separate files?
It seems easy for a Desktop app, but I can't seem to find a suitable way of versioning for an asp.net web application.
NB I'm not sure that I have been totally clear with my question.
What I want to know is how to build and auto increment a version number for an asp.net application.
I'm not interested in how to link it with svn.
I think what you are looking for is something like this: How to auto-increment assembly version using a custom MSBuild task. It's a little old but I think it will work.
For my big apps I just use a incrementing version number id (1.0, 1.1, ...) that i store in a comment of the main file (usually index.php).
For just websites I usually just have a revision number (1,2,3,...).
I have a tendency to stick with basic integers at first (1,2,3), moving onto rational numbers (2.1, 3.13) when things get bigger...
Tried using fruit at one point, that works well for a small office. Oh, the 'banana' release? looks over in the corner "yeah... that's getting pretty old now..."
Unfortunately, confusion started to set in when the development team grew, is it an Orange, or Mandarin, or Tangelo? It looks ok. What do you mean "rotten on the inside?"
... but in all honesty. Setup a separate repository as a master, development goes on in various repositories. For every scheduled release everything is checked into the master repository so that you can quickly roll back when something goes wrong.
(I'm assuming dev/test/production are all separate servers, and dev is never allowed to touch production or the master repository....)
I maintain a system of web applications with various components that live in separate SVN repos. To be able to version track the system as a whole, I have another SVN repo which contains all other repos as external references. It also contains install / setup script(s) to deploy the whole thing. With that setup, the SVN revision number of the "metarepository" could possibly be used for versioning the complete system.
In another case, I include the SVN revision via SVN keywords in a class file that serves no other purpose (to avoid the risk of keyword substitution breaking my code). The class in that file contains a string variable that is manipulated by SVN and parsed by a class method.
An inconvenience with both approaches is that the revision number is not automatically updated by changes in the externals (approach 1) or the rest of the code (approach 2).
During internal development, I'm using milestone numbers (M1, M2, M3...). After release, I'll probably just update dates ("the January 2009 update").