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.
Related
In Biztalk, many artifacts (e.g. schema, pipeline etc) are used in some location like sendport, receivelocation etc.
Each time when we want to deploy an update version to Biztalk, it will said the artifact is being used. But we dont know where it is being used and we need to check all receivelocations, sendports and other places one by one.
Is there any faster approach such that we can know where the artifact is used?
Thanks.
BizTalk documenter might be of some use. It documents in what ports a map is used. (Full Disclosure: I am now a developer on the latest versions)
And just released there is a new tool called BTSG NoS Addin will find your external dependencies.
You can check this using Admin Console of Biztalk.
For example if you want to know where a pipeline is used, just right click on pipeline and click on 'view dependencies' and now you can view all those places where pipeline is being used/refered. click on Number and it will bring to that place
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.
Is it possible to exclude a folder in a web project from being published? We've got some documentation and scripts that included in a particular project folder, and are added to the project, but when I do a VS publish, I don't want them to go up to the production server.
I know they shouldn't be in the project, but I thought I'd find a workaround before I try to convince the owner to modify the way he's doing things.
Old question, but I found if I mark the folder as hidden in Windows Explorer, it doesn't show/publish in your solution.
This is good for example to stop original photoshop images being included in uploads which aren't used and are big. Anything more complex though you'll probably want to write your own publish tool.
This doesn't answer your question, exactly, but my feeling is that unless you are a single developer publishing to a server, you would be better off doing builds on a dedicated workstation or server using MSBuild (or some other building and deploying solution) directly (and thereby would be able to very granularly control what goes up to production). MSBuild can not only build, but using some extensions (including open source types), it can also deploy. Microsoft has a product called MSDeploy in beta, and that might be an even better choice, but having no experience with it, I cannot say for certain.
In our situation, we have a virtual workstation as a build box, and all we have to do is double click on the batch file that starts up an MSBuild project. It labels all code using VSS, gets latest version, builds the solution, and then deploys it to both servers. We deploy exactly what we want to deploy and nothing more. We're quite happy with it.
The only downside, if it could be considered a downside, is that at least one of us had to learn how to use MSBuild. VS itself uses MSBuild.
For the files you don't want to go, loop at the properties and set the 'Copy to Output Directory' to 'Do not copy'
This option is not available for directories, however.
Can you not exclude them from the project through visual studio to stop them being published. They will the still exist in the filesystem
The only way that you can do this to my knowledge would be to exclude it from the project, do the publish, then re-include it in the project. That can be an issue.
There are probably much better ways to solve this problem but when we publish a build for our dev servers, we'll run a batch file when the build is complete to remove the un-needed folders and web.configs (so we don't override the ones that are already deployed).
According to http://www.mahingupta.com/mahingupta/blog/post/2009/12/04/AspNet-website-Exclude-folder-from-compilation.aspx you can just give the folder the "hidden" attribute in windows explorer and it won't publish. I tested this and it works for me.
Seems like a straightforward solution for quick and dirty purposes, but I don't think it will carry through our version control (mercurial).
Select all the files that should not be published.
Go to Properties
Set
Build Action -> None
Have to repeat the process for each sub-directory.
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").