What is team foundation server(TFS)?
- Here is the Architecture of TFS
First lets talk of small teams(as we realy work in our country)
If you are working on your own, or as part of a small team (5-person or less), than Team Foundation Server Workgroup Edition may be the right choice for you. Team Foundation Server Workgroup Edition offers all of the collaboration, security and performance advantages of the standard Team Foundation Server. The only difference is that Team Foundation Server Workgroup Edition is limited to 5 members. If your needs ever grow, you can move to the standard Team Foundation Server by simply using a new product key
Ok now we know we need TFS work group edition to work.How we get is the problem isn't it?
They say(Microsoft) we can get TFS work grop edition freely when we buy with followings.
Visual Studio 2005 Team Suite
Visual Studio 2005 Team Edition for Software Architects
Visual Studio 2005 Team Edition for Software Developers
Visual Studio 2005 Team Edition for Software Testers
Visual Studio Team Edition for Database Professionals
( I took above names from Microsoft sites.Yo can click these links to go that places and study more of them)
Now lets talk of large teams(Hopefully we will work in future)
Team Foundation Server’s efficiency benefits the largest enterprises as well; including those who are geographically distributed. To support teams of up to approximately 3500 members, Team Foundation Server should be installed in a dual-server configuration. The services required for Team Foundation Server (the XML Web Service Interface, Reporting, etc) reside on the application-tier server, while the database portions of Team Foundation Server reside on the separate data-tier server.
To support teams of up to 800 members, the application-tier server should be configured with a single 2.8 GHz CPU and 1 GB of RAM and the data-tier server should be configured with a dual 2.7 GHz CPU and 4 GB of RAM.
To support teams of up to about 3500 members, the application server should be configured with a dual 2.8 GHz CPU and 4 GB of RAM and the database server should be configured with a quad 2.7GHz CPU and 16 GB of RAM
Clustering, Fail-Over and High-Availability
Team Foundation Server can support the needs of the most demanding development environments. Because Team Foundation Server uses SQL Server 2005 for its data storage, it is able to leverage SQL Server 2005’s inherent security and reliability.
In environments where additional availability is required, Team Foundation Server, in conjunction with SQL Server 2005 can be configured to support clustering, fail-over and/or high-availability.
Adding support for clustering, fail-over, and high-availability requires additional and specific hardware recommendations. For more information, see the Team Foundation Server Planning Guide.
So far i learned that much.Ill tell reminder later.Till then take care bye
=============================================================
OK IM BACK TODAY .1 more day to 2008!!!!!!!!!!!!!!!!!!!!!
Today im going to talk about how TFS at work(As i learnt)
TFS mainly forcus on Team Projects.This is how it do that.
Software development is a team activity now more than ever. When you think about software teams, what are the key objects that come to mind? First and foremost is the simple notion of a project. Not project in the Visual Studio solution sense of the word, but rather a set of individuals with shared goals to be achieved in a desired time. Team Foundation Server calls this a team project. In life-cycle tools today, this is mainly just a concept and not a physical object at all. You'll find tools either have no notion of this fundamental concept, or they have several different notions that are not consistent.
To deliver tight integrations, a software life-cycle tool suite must have a common, shared notion of a team project. Also, an actual object is needed that is managed with persistent data, so that automation, relationships, and communication are possible. Team projects are central to everything Team Foundation Server provides. Team projects are surfaced in several places, primarily inside Visual Studio in the Team Explorer and through the Team Project Web site (based on Windows Sharepoint Services .Its a big story :)
Ok lets look at what we are realy going to!!
Every team follows different processes and procedures. You may want your Web site to look a certain way, you may have specific guidance for how development gets done, you may have your own templates for documents, and you may want to organize your documents using a specific hierarchy. If your team is larger, you may also have special roles for team members and specific permissions assigned to these roles.
Team Foundation Server provides a completely customizable way to define all of the data surrounding a team project and encapsulate this information into a methodology template. When a new team project is created, Team Foundation Server uses the methodology information to automatically configure the team project, including creating the team project Web site. Methodologies can be exported, customized, shared, loaded, and even bought and sold by third parties.
With Team Foundation Server, you can create new team projects quickly without having to do hours or days of setup work in various tools using various techniques.
To help get you started, Microsoft will provide two methodologies for use with Team Foundation Server: MSF Agile and MSF Formal. MSF Agile draws on the best practices of the Agile community and the Microsoft Solutions Framework to deliver a lightweight, easy-to-use methodology geared toward small teams who must move quickly. MSF Formal is targeting larger teams who require more control over their development processes. MSF Formal is designed to help teams achieve CMMI Level 3 maturity.
Another thing that supports TFS is Version Control and Work Item Tracking.
At the heart of software development is the edit/compile/unit test/debug cycle. Surrounding this is usually a team build (often nightly), integration and system testing, and bug submission and resolution. The key objects being created and managed here are source code, work items, builds, and tests. You'll see the relationship between these objects offers significant integration and automation opportunities that Team Foundation exploits.
Source code is another obvious object that must be tracked and managed for software teams. Software configuration management/version control tools are widely seen as a necessary part of any reasonably sized software team. Team Foundation Server includes a new version control solution that supports many advanced SCM features such as namespace versioning, automatic check in, and changes sets. Team Foundation Server also includes some new and innovative SCM features such as putting work on hold, sharing a change with another developer before check-in, and integrated check-in policies .(following image)
Team Foundation Server's Version Control will not replace Microsoft's Visual Source Safe (VSS). VSS will continue to be developed and supported for smaller teams (< 5 people) requiring only version control capabilities. Team Foundation Server's Version Control is targeted at teams of five or more that require more advanced version control features and integrations with other life-cycle tools.
Work items is another major object that teams use to prioritize and track and work. Work comes in many forms: bugs, tasks, features, requirements, change requests, issues, and so forth. Most teams today need to deal with several different tools to make sure they are getting a clear picture of everything that needs to be done. Team Foundation Server has the flexibility to manage all of these types of objects as different work item types, but tracks them in one place, allowing for cross work item type reporting and queries. All work items include things such as a description, assigned user, and states for tracking progress. However, with Team Foundation Server, work item types are completely customizable, which allows your team to define the fields, rules, state model, and form layout that make sense for your team.
The real power of Team Foundation Server comes not from separately managing the source code and work items, but rather from their integration and the automation that can be done with this relationship. By simply enabling a check-in policy, software teams can make it required that developers specify one or more work items whenever they perform a check-in. This is easy to do by having work items readily available in an integrated Pending Check Ins window.(above image)
Checking the box next to the appropriate work item links the "why" of a change to the "what." The benefits to productivity and the automation possibilities of this simple link have yet to be fully realized in tools today.
One example of the automation benefits is the support of automated state transitions on work items. In the past, developers would check in their code, and then go to their bug tracking tool to transition one or more bugs into the next state ("Ready for Test" or "Resolved," for example). With Team Foundation, a developer can simply indicate in the pending check-in dialog box which "check-in action" they want to occur after the check-in has finished. If they select the "resolve" action, the work items will be automatically transitioned to the next state. This reduces work for the developer, increases the flow of changes through the life cycle, and makes for a cleaner hand-off between the developer and tester. Testers who receive this work item to verify can easily access and review the source code changes by following the link recorded in the work item.
OOOK.now lets see how TFS achive Build Management and Testing.
Another object that is central to a software development team is the "build." Similar to the concept of project, builds are often treated as second-class citizens in life-cycle tools, and most companies are left to develop their own in-house build systems. A build is simply an object that identifies the manufactured software product. The source code and build scripts are the raw materials; the manufacturing process begins when a build is started; and the resulting libraries, executables, and other supporting files are the result.
The whole build process does not really stop there because after the freshly constructed product drops off the assembly line, it must go through testing to ascertain its quality. Typically, a set of smoke tests is performed. These tests exercise the most basic or core functionality of the product to determine its overall health. Think of it in terms of going to see the doctor. Your doctor always checks your weight and blood pressure, listens to your heart, and pokes around in your ears and throat. Once general health has been established, more detailed testing can be performed.
This is the build configuration image.
Now lets see wwhy all these are needed.Of course.Project Management.
Project Management
Of course a software team would not be complete without the individuals who do the work of defining what the product should do and managing the teams to deliver on time and on budget. Team Foundation Server has been designed to improve the collaboration, communication, and management of software development teams. There are several capabilities for both the project leader and the requirements definer (a.k.a., analyst, program manager, or product manager). Central to these roles is the concept of the team project discussed previously. With both the team project and methodology, Team Foundation Server already delivers a set of work item types and a team project Web site populated with project templates and process guidance customized for your team and your organization. But what objects other than work items are interesting to the project manager/analysts? One that comes to mind is a project plan. A close second is specifications or requirements. Many software development efforts start with a high-level vision document and an Excel spreadsheet of key work items, including things like priority, development effort estimate, and a brief description. These could take the form of functional requirements, scenarios, or quality of service requirements. In any case, you can usually find an Excel spreadsheet being used on projects to track these important items, issues, or other things. Team Foundation leverages the power of Excel for its ease of entry and tracking, but integrates the locally stored XLS files more formally into the overall development environment by linking them directly to work items in the Team Foundation Server database.
Analysts using Team Foundation Server can start editing in Excel and then "publish" their lists to Team Foundation Server, creating new work items that can be tracked. They can continue to use Excel to update these items by synchronizing their spreadsheets with the existing work items database. Communicating work items and keeping lists up to date suddenly becomes much easier and more practical.
It is also possible to create new spreadsheets from data in the work item tracking system. Say you need a quick graph for a presentation you are doing in an hour. With Team Foundation Server, you can create a query for all the Priority 1 Bugs and Tasks that are active on Team Projects A and B. From this query, you can select "Open in Microsoft Excel" and then build a graph quickly based on this data.
The possibilities are endless, and the support for the Excel scenario has been well designed and thought out. For example, you can take work items offline by exporting them from Team Foundation Server to Excel and making changes while you are on the go. Edit owners, change priorities, and add new items. Then when you connect back up, all this data is synchronized to the work item database.
You might be asking yourself, "What if others have made conflicting changes to the same work items while I am off-line?" The answer is that an easy-to-use compare/merge utility will help you resolve any of these conflicts.
You can see in above figure Work Items in Visual Studio.
Now lets make a conclution what is TFS.
Conclusion
Team Foundation Server is a software life-cycle tool designed specifically to improve software development team collaboration and increase productivity. Team Foundation Server delivers version control, work item tracking, project management, and build management capabilities. Above all, it focuses on the linkage between the central objects a software team manages, and on the unique integration and automation possibilities these links provide.
Ok.Thats it for today.
see you all in new year 2008.
HAPPY NEW YEAR
