Here's a guide on how to create a two - branch TFS2010 solution. It's as much a reminder for me as it is information for anyone else who might find this useful.
1. Create a new Team Project on the TFS server. Mine is called 'Baseline'
2. Create yourself a new folder on your C: drive called 'Visual Studio 2010'. Create another folder within this to store your project files, i.e. c:\Visual Studio 2010\Baseline.
3. Open the Solution Control Explorer (I'll refer to it from now on as TFS Explorer) for the Baseline Team Project. Use the Workspace drop down to create a new Workspace and call it 'Baseline'. Set the TFS working folder to the top level folder of the TFS project (i.e. Baseline), and the local folder to whatever you created in 2.
4. Create two new folders under the Baseline top level in TFS, call them Dev and Release.
5. Create a new VS2010 BLANK solution. Call it Baseline and place it into the Dev folder. If this has worked proerly you should now be able to see c:\visual studio 2010\baseline\dev\baseline in windows explorer, and see the .sln file and the .vscc file in this folder.
6. Add a new web project to the blank solution. Call it what you want (I've called mine BaselineWeb) and make sure it gets created inside the folder structure in 5. So you should have c:\visual stuido 2010\baseline\dev\baseline\baselineweb\*.* where *.* is all the .aspx, web.config files etc. for the website.
7. Next you need to check all this stuff into the TFS server.
8. Right click on the Dev folder in TFS explorer and select 'Convert to Branch'. The icon for the Dev folder in TFS explorer should have changed from the standard yellow folder to a white branch icon.
9. You now need to Branch the Release folder. Right click on the newly branched Dev folder and select Branch. The target needs to be $Baseline/Release/Release (i.e. you're adding a new Release folder under the original one). Commit this to the server. The Release/Release folder should also have had its icon replaced with a Branch icon.
10. You should be good to go now. You can merge the content of the Dev folder into the Release folder and vice versa.
Friday 31 December 2010
Thursday 30 December 2010
Volunteering with Community Groups (2)
The 'mailshot' that I sent out on Boxing Day has received a lot of interest. I have already been contacted by half a dozen different organisations in the local area who are interested in getting some help. This probably means that I won't be able to get to them all straight away but I'm thinking about some other ways in which I could still help without devoting time to design / development work.
Improving Database Development
Going hand in hand with my exploratory work on Team Foundation Server 2010 I have been thinking recently about how my team can improve the quality of our database work too. We tend to keep things simple with databases by using just tables and stored procedures. The stored procedures are always extremely simple - either a read, or an insert, or an update. We don't store any advanced application logic; I have always found T-SQL difficult to program in and we use VB.NET for all the complicated stuff.
We're facing a few problems. All of us are working on one database at the same time which I have read in a couple of places (including K. Scott Allen's excellent blog on the subject) that this is a bad thing. We also have different versions of the database without really knowing what the differences are between them and it's difficult to keep track.
After reading around on the subject I'm planning on introducing the following changes:
1. I would like to give each developer a sandbox area in which they can work in isolation. I am going to look at how this can be achieved through the use of a virtual desktop.
2. I want to introduce a scheme repository that developers write change scripts to and can access to get the latest database build. Again I have taken inspiration from K. Scott Allen. The repository will be a single database table with some information about the version, update date, author etc. and also the location of the text file that contains the script. So the first entry will be 1.0 and will be the build script for the database as it stands at the moment. Every time a developer makes a change they will use a custom app (I need to write this) that will create a new entry in the database and also write the script to a text file. I then need to have a process that will let someone get the latest build by creating one giant script encompassing the baseline and all changes made. The developer could also pick a specific version to build up to, and it would only include all changes up to that build, leaving out any newer changes.
I think this will be a big help for us in terms of organising and moving forward. Hopefully I can post some more on this subject when I get it all up and running.
One last point; I know that Team Foundation Server 2010 supports database projects that can source control all the objects in a database but we don't have the correct version - it's not included in the Professional license (I think Premium and Ultimate only).
We're facing a few problems. All of us are working on one database at the same time which I have read in a couple of places (including K. Scott Allen's excellent blog on the subject) that this is a bad thing. We also have different versions of the database without really knowing what the differences are between them and it's difficult to keep track.
After reading around on the subject I'm planning on introducing the following changes:
1. I would like to give each developer a sandbox area in which they can work in isolation. I am going to look at how this can be achieved through the use of a virtual desktop.
2. I want to introduce a scheme repository that developers write change scripts to and can access to get the latest database build. Again I have taken inspiration from K. Scott Allen. The repository will be a single database table with some information about the version, update date, author etc. and also the location of the text file that contains the script. So the first entry will be 1.0 and will be the build script for the database as it stands at the moment. Every time a developer makes a change they will use a custom app (I need to write this) that will create a new entry in the database and also write the script to a text file. I then need to have a process that will let someone get the latest build by creating one giant script encompassing the baseline and all changes made. The developer could also pick a specific version to build up to, and it would only include all changes up to that build, leaving out any newer changes.
I think this will be a big help for us in terms of organising and moving forward. Hopefully I can post some more on this subject when I get it all up and running.
One last point; I know that Team Foundation Server 2010 supports database projects that can source control all the objects in a database but we don't have the correct version - it's not included in the Professional license (I think Premium and Ultimate only).
Sunday 26 December 2010
Harrogate Premier Bathrooms
Today I published my first website for a client (ok, so the client is my Dad and his business partners). Small three page site just to get them going but the design is neat and I have some good ideas to implement in 2011. Here's the link: Harrogate Premier Bathrooms.
Volunteering with Community Groups
Today I sent an email to around 60 community groups based in Warrington to ask if they would like any help from me on a volunteer basis. I have tried looking for volunteer work before through the IT4Communities website but not had any takers.
I understand from working with community groups and small businesses on the Knowsley Community Tradenet project that time is the scarcest resource for the people who run these organisations and I hope that by offering my time and skills I can maybe help one or two IT - based projects get off the ground.
I took a list of contacts from the Warrington Community Information Directory.
I understand from working with community groups and small businesses on the Knowsley Community Tradenet project that time is the scarcest resource for the people who run these organisations and I hope that by offering my time and skills I can maybe help one or two IT - based projects get off the ground.
I took a list of contacts from the Warrington Community Information Directory.
Wednesday 22 December 2010
Team Foundation Server 2010 (3)
Came across a problem referencing a .dll today. The application that I am migrating into TFS2010 as part of the learning process relies quite heavily on the Ajax Control Toolkit for its UI and the .dll has to be included as part of the solution.
Unfortunately it's not enough to reference the library as was the norm in VS2008 because the build server couldn't see it. I tried creating a folder called C:\Build on my laptop and the build server and placing the file in both these locations but that didn't solve it either. Fortunately I found the answer about half way down this thread; you have to include the .dll in the workspace structure of the solution otherwise it won't work. So I created a folder called References inside the project folder of the branch I'm trying to build, added the .dll to it and then referenced the .dll from this location in my VS2010 solution. Worked like a charm.
It looks like TFS ignores any .dll you add this way for build purposes; I guess you don't want your build failing because the 3rd party .dll you are using has an unassigned variable lurking. I then tried merging the dev branch into main to see if TFS was smart enough to replicate the referencing and it was, there is now a folder called References in the Main workspace and the solution file for Main contains a reference to that file. Very slick indeed.
Unfortunately it's not enough to reference the library as was the norm in VS2008 because the build server couldn't see it. I tried creating a folder called C:\Build on my laptop and the build server and placing the file in both these locations but that didn't solve it either. Fortunately I found the answer about half way down this thread; you have to include the .dll in the workspace structure of the solution otherwise it won't work. So I created a folder called References inside the project folder of the branch I'm trying to build, added the .dll to it and then referenced the .dll from this location in my VS2010 solution. Worked like a charm.
It looks like TFS ignores any .dll you add this way for build purposes; I guess you don't want your build failing because the 3rd party .dll you are using has an unassigned variable lurking. I then tried merging the dev branch into main to see if TFS was smart enough to replicate the referencing and it was, there is now a folder called References in the Main workspace and the solution file for Main contains a reference to that file. Very slick indeed.
Tuesday 21 December 2010
Team Foundation Server 2010 (2)
I've spent the majority of the day trying to teach myself how to set the server up and how it works with Visual Studio 2010. Fortunately it's all pretty intuitive and I think I have it figured out to a level where the team can make use of it. It is going to save us a lot of time and make us work better.
There were a few different topics that I looked at. I followed Jason Zander's tutorial on his blog and that taught me how to do the install, create a project in TFS and then add code to it from VS2010 and make changes. What this doesn't go into is two slightly more advanced topics - using the Source Control Explorer and Branching. It also skips over Workspaces (basically the 'Set Working Directory' option that was in Visual Source Safe).
Branching allows you to create multiple copies of the same application and keep them in different states simultaneously. The simple example I saw on Codeplex has a three Branches - Main, Dev and Release. The Dev Branch allows the dev team to work on one copy of the application while the Main and Release Branches are kept 'clean'. When the dev team has completed something and tested it the changes can be merged into Main and Release, built and published. Another benefit of this is that if something urgently needs doing to the Release version you can implement the change on Release and propagate the change back down to Main and Dev. This seems like a really powerful tool.
The Source Control Explorer is what manages these Branches. Once you have created the Main Branch you can populate it with a blank solution from VS2010 and then Merge this into the other Branches. I guess there's maybe room for a Test Branch too.
Creating a Build is really easy (once you figure out how to give the correct permissions to write to the build folder on the server) and it drops out a compiled web app which you can quickly drop onto a server. You can specify builds for the different Branches and schedule these to run multiple times throughout the day. I guess the dev build needs to happen pretty frequently, the release build could be run manually to save the server overhead.
The irritations caused by Source Safe are pretty much gone. Tomorrow I'm going to install VS2010 on another development laptop and see how easy / difficult it is to get a copy of the source code and make changes to it.
There were a few different topics that I looked at. I followed Jason Zander's tutorial on his blog and that taught me how to do the install, create a project in TFS and then add code to it from VS2010 and make changes. What this doesn't go into is two slightly more advanced topics - using the Source Control Explorer and Branching. It also skips over Workspaces (basically the 'Set Working Directory' option that was in Visual Source Safe).
Branching allows you to create multiple copies of the same application and keep them in different states simultaneously. The simple example I saw on Codeplex has a three Branches - Main, Dev and Release. The Dev Branch allows the dev team to work on one copy of the application while the Main and Release Branches are kept 'clean'. When the dev team has completed something and tested it the changes can be merged into Main and Release, built and published. Another benefit of this is that if something urgently needs doing to the Release version you can implement the change on Release and propagate the change back down to Main and Dev. This seems like a really powerful tool.
The Source Control Explorer is what manages these Branches. Once you have created the Main Branch you can populate it with a blank solution from VS2010 and then Merge this into the other Branches. I guess there's maybe room for a Test Branch too.
Creating a Build is really easy (once you figure out how to give the correct permissions to write to the build folder on the server) and it drops out a compiled web app which you can quickly drop onto a server. You can specify builds for the different Branches and schedule these to run multiple times throughout the day. I guess the dev build needs to happen pretty frequently, the release build could be run manually to save the server overhead.
The irritations caused by Source Safe are pretty much gone. Tomorrow I'm going to install VS2010 on another development laptop and see how easy / difficult it is to get a copy of the source code and make changes to it.
Team Foundation Server 2010 (1)
I have been working as part of a team of six developers for just over a year now. This has been the first time in my career that I have been part of such a team and in that time we have created a lot of components. These are scattered across a range of applications - web apps, web services, databases, SSIS packages and standalone .exe files that we run from servers on a schedule.
We're at the stage now where controlling change amongst the team is difficult. We are using Visual Source Safe as our source code repository and it's not brilliant. I'm never 100% confident that when I try and build a new version of the application that I'm working on and publish it to our test environment that it will have all the most up to date code in it. So instead of moving forward with functionality I'm spending time bug fixing changes so that I can get a demo working for customers.
I'm also finding the whole build process very unsatisfactory. At the moment I have a Visual Studio 2008 solution with a dev project that we're all contributing to and a test project that contains just the files I need to run a particular app. Creating a build involves knowing which of the files have changed, copying them into the test project, remembering to change the namespaces and then publishing to the test server. It's a slow and irritating process.
I also have the attitude of team members to deal with. Communicating with people when you all sit in a space that's about 10m square should be simple but it's not. I'm not getting told when things change and only find out about changes when I try and publish a version of the app and it stops working because a datatype has changed in the database.
All this is stopping us progressing. Fortunately we have just acquired some MSDN developer licenses that allow us to install Visual Studio Pro 2010 and Team Foundation Server. I have been reading plenty of stuff on the web about how these development tools will help to resolve the problems that I'm facing and move the team forward. So I'm going to spend the next few months concentrating on developing the practices and procedures necessary to improve our efficiency and quality. I would also like to explore the opportunities that Agile programming will bring to the team and see how well it fits with what we do because I think we can learn from that too. The next set of blog posts will all record my findings as I carry out this piece of work.
We're at the stage now where controlling change amongst the team is difficult. We are using Visual Source Safe as our source code repository and it's not brilliant. I'm never 100% confident that when I try and build a new version of the application that I'm working on and publish it to our test environment that it will have all the most up to date code in it. So instead of moving forward with functionality I'm spending time bug fixing changes so that I can get a demo working for customers.
I'm also finding the whole build process very unsatisfactory. At the moment I have a Visual Studio 2008 solution with a dev project that we're all contributing to and a test project that contains just the files I need to run a particular app. Creating a build involves knowing which of the files have changed, copying them into the test project, remembering to change the namespaces and then publishing to the test server. It's a slow and irritating process.
I also have the attitude of team members to deal with. Communicating with people when you all sit in a space that's about 10m square should be simple but it's not. I'm not getting told when things change and only find out about changes when I try and publish a version of the app and it stops working because a datatype has changed in the database.
All this is stopping us progressing. Fortunately we have just acquired some MSDN developer licenses that allow us to install Visual Studio Pro 2010 and Team Foundation Server. I have been reading plenty of stuff on the web about how these development tools will help to resolve the problems that I'm facing and move the team forward. So I'm going to spend the next few months concentrating on developing the practices and procedures necessary to improve our efficiency and quality. I would also like to explore the opportunities that Agile programming will bring to the team and see how well it fits with what we do because I think we can learn from that too. The next set of blog posts will all record my findings as I carry out this piece of work.
Graduated!
Last week (Wednesday 15th December, 3pm to be precise) I attended my graduation ceremony at the Liverpool Philharmonic Hall and received my certificate from the vice chancellor. I am now officially a Master of Science! It was a great day and made a nice change to be in a room full of happy people all celebrating something.
Subscribe to:
Posts (Atom)