November 2007 - Posts
What has changed for Visual Studio Team Edition for Database Professionals (aka VSDB, DB Dude) in the 2008 edition?
- Installation: No more additional setup. In Visual Studio Team System 2008 VSDB completely integrated in the standard setup, so no more additional downloads. All you have to do is to make sure the Team Database Edition option is checked in the features to install window. The database project functionality is only available in two of the Visual Studio Team System SKU's:
- Visual Studio Team System 2008 Database Edition.
- Visual Studio Team System 2008 Team Suite.
- The Visual Studio Team System 2008 Database Edition is based on the v1.0 functionality plus the Service Release 1 functionality.
- Solution Explorer performance improvements, especially when your project has large number of objects stored under a single node instead Solution Explorer.
What about the great features of VSDB 2005 power tools? Not available yet. MS trying to release a new VSDB 2008 Power Tools release targeting later this month.
According to Jeff Beehler:
I'm happy to announce that the next Community Technology Preview of Rosario (officially known as Microsoft® Visual Studio® Team System code name “Rosario” November 2007 CTP) is now available. Customers can immediately begin downloading the VPC images from our download page.
Download and check what's coming up next for Visual Studio Team System!
I uploaded my presentation and demo, done in DevAcademy2. Now you can download, use and review it.
Presentation - DEV215 Integrating Databases Into ALM
Demo - DEV215 Integrating Databases Into ALM
On the last meeting we had the great pleasure of having a true Scrum Master as our lecturer. Since then we had a short break and the next meeting will take place (on our regular spot, Microsoft offices in Raanna) tomorrow.
The main topic will be requirement management; Assaf Alpert from Matan consulting will start with a methodological overview of the concept behind it and then will go into the details of the place requirement management hold in the software lifecycle.
On the second hour we will have the Yitzhak Saft from KCS demonstrate a requirement management solution they developed on top of Team Foundation Server.
See you tomorrow
This is the second post and part of 4 posts about eScrum, the first post introduce Scrum and eScrum. This post workaround synchronization between VSTS and eScrum web client.
VSTS and eScrum web client are working together as two platforms for one team project.
There is a complete transparency between them. So each developer have the ability to decide where he prefers to see, create or manage the project.
Work item type in VSTS is equal to the different tabs in eScrum web client.
Due to the seamless synchronization, you can add work item from VSTS Team Explorer or eScrum web client and display them in both platforms.
For example, you can view products that were created in eScrum, in VSTS and
you can see products that were created in VSTS, in eScrum.
The only notable down side for web client is that there is no auto refresh, so if products were created, for example, in VSTS you won’t see them in the web client until you will update eScrum cache.
The quick work-around is to switch between the projects from the project drop-down list in the right corner of the page.
If you have the same problem in VSTS (a product created at the web client and is not displayed in VSTS) you probably need to rerun the work item query. You can do so from the icon “Run Query” in the toolbar.
As part of my job as a consultant at SRL, I get to visit many companies and see different implementations of Team System. Some companies thought that Team System is just as a fancy replacement for VSS and without any preplanning they installed TFS and started working with it. Shortly after they started noticing they actually had to work harder to keep the system updated. I always tell them my motto for every supporting system in general and especially regarding Team System:
Ask not what you can do for Team System - Ask what Team System can do for you !
Bellow is the list of the top 5 most common misperceptions regarding source management in Team System you should be aware of (and hopefully avoid):
1. Team Project - "Do we need a team project for each project we create ?"
The name "Team Project" is built from two words, "team" and "project". For some reason, people tend to read only the second part and totally miss the "team" purpose of this object. Team Project are often used as a container for solutions and projects in the same team, I've even seen team projects being used for branching monthly versions of the same product.
Team Project is meant to be used for a team that works for a shared goal. Your teams can have different managers, sit in different buildings, work on different products and even develop using different languages. as long as your teams have a seared goal (such as an application on a major version) they should use a single Team Project.
2. Workspaces - "Why bother with many workspaces? one is enough !"
One of the most common mistakes I see is the misusage of workspaces. Programmers often think that workspace is just a fancy name for the VSS equivalent of "working directory". By think that, programmers usually create a single workspace and map it to the tree's root folder. By doing so, they can't use all the advantages that workspace allow. advantages such as isolating your development on different products or switching between different versions of the same product and many more.
Workspaces are great for keeping your work isolated, you should create and work on different workspaces for each product\version.
3. Changeset - "Was the bug fixed on changeset 32453 or 32468?"
As I mentioned in the previous paragraph, some people think that Team System is just VSS with new icons. they may use all Team System as to offer (such as work items, builds etc`), but they don't create any linkage between the different data items. must commonly is not to link changesets to the relevant work items and use only comments (and labels) to manage their code.
Changesets are a powerful objects that make a major change in the way changes are stored in the source control and way you should manage changes in your code. Changesets are used to wrap all the files (and folders) that were checked-in to the server. This ability on its own is enough, but when linking the changeset to the work item that initiated the changes in your code, you create a real-time documentation for the reasons of the code changes for each row of code in your file.
4. Work Items - "Just fill the title and write the other info in the description"
A programmer once told me that he think Work Items are BAD, he doesn't understand what he need to do and often have to call the initiator of the work item for clarifications. Well, in some aspect he is right. don't get me wrong, I think work items are very important objects, but when companies don't customize the structure or over-customize (by required many fields) they create the opposite action.
When customizing your work items, you should avoid making the process too long or too descriptive, keep all the fields understandable and don't create a cumbersome process that will create overhand and make the participants unwilling to provide important information.
5. Branch - "We don't need branching, we are a small development group"
The sentence above I normally hear for small development groups. they tend to think that if they are only 5-8 programmers than they don't need any versioning or branching. In many cases if they do use branching it is used as just a backup folder and not as part of the application lifecycle.
Branching is meant to "freeze" the state of your code to and allow your team to work on different version of the same application (for example production version, QA version and development version).
Branching is very impotent no meter the size or of your development team or the fact that you may sit next to one another. Branching should be part of your development lifecycle and should be planed during the planning stage.
In summary, Team System has many features and tools to assists your development efforts. When implementing any system you should always plan your steps and be familiarize with advantages the new system has to offer.
Good Luck!
Access to Team System source control and work item tracking is available to java developers using Eclipse.
The Teamprise Plug-in for Eclipse integrates with TFS team explorer and access to team projects.
After Teamprise installation and updating eclipse with it, the “Team” option will appears under your project,
sharing your project with TFS team explorer is necessary under excising team project that was created on the TFS.
Now you can start enjoying the TFS team explore abilities such as work items, documents, reports, source control and even project portal.
Through “Team” there is most source control option such as check in, check out, lock, get latest or specific version, working with labels and mange workspaces.
In order to see team explorer view in eclipse: click “Window” tab in the toolbar, “Show View”, “Other”, in “Teamprise” folder chose “Team Explore and click o.k.
Adding team project: right click on the server name , Add exciting team project.
Eclipse Team explorer provide view and edit work items and queries through the pending changes view or directly from team explorer.
In order to view pending changes, or history: right click on project name and Team.
hello,this is the first, and 1of 4 blogs about eScrum.
Scrum is an agile software development method for project management, it’s a set of interrelated practices and rules that optimize the development environment.
A Scrum project is a monthly process and useful product functionality is delivered as requirements, architecture, and design to the customer.
EScrum confirm all scrum rules and methodology .with eScrum you can create products, product backlog, manage sprints, sprint backlogs, view and investigate reports, update the process every day. All of this and more ensure that eScrum provide scrum platform.
A Product is a combination of a Product Backlog, a Product Owner, and a list of Team Members who will participate in the Sprints.
Each product divided to product backlog, which is a single prioritized feature with a baseline cost estimate.
A Product Owner is the single person in charge of keeping the Product Backlog complete and up to date. The Team Members added to a Product will show up in the Owner drop down for Product Backlog Items.
Each sprint is time limited, the default is 30 days. The Product Team selects a set of Product Backlog Items which they think they can deliver on in the given period of time and works on those features, producing a working product at the end of the Sprint. A Scrum Master is assigned to a sprint to facilitate the Scrum process and to remove any impediments to the team.
A Sprint Backlog is a breakdown of the specific tasks necessary to implement all of the functionality of a set of Product Backlog Items. Because only those features accepted by the Sprint Team will be worked on, all Tasks generated for the Sprint must be directly associated with a Product Backlog Item.
To be able to properly track Sprint status and have a valid Sprint Burn down graph, Sprint Team Members should daily update the actual hours worked on tasks in the “Daily Scrum”.
TFSBuildLab 1.0 is released on CodePlex.
This is a project to simplify the day to day operations when using automated builds on TFS.
Read more about it here.