Team Foundation Service –Team Rooms

So its Monday. Then our team discovered Team Rooms in Team Foundation Service.


This is basically, a team chat window.


So we configured it to show all notifications and as we try out some emoticons, a build failed. So back to work! I promise to blog about this experience soon!


How Team Foundation Service enabled, efficient and saved a team of Ninjas a number of times!

I have not blogged for a few weeks now because of my left and right projects – running around to places and I just had to do a blogpost today to highlight one of the best tool in my teams arsenal: the TFS Service (


Disclaimer: Today it is called TFS Preview, Preview, It means its not on its not yet a full product like a beta. So if you are going to try this out, even on a live project like me, please make sure you have a fallback, back-ups and alternatives. I on the other hand, saw the potential early on and I weigh the risks involved in contrast with the benefits that it would give my team – thus I decided to go ahead. But that’s just me.

So what’s Team Foundation ? TFS is a collaboration platform for application development thru its life cycle. It is used to be a stand-alone product that needs a Windows Server Platform and a list of hardware and software requirements  for you to take advantage of its capabilities. What Capabilities? If you are a developer or a development project manager, you will love TFS. TFS gives you the ability to manage your team development process. In a nutshell id like to give a simple run-thru. A scenario when you already have the architecture of the application to be built and it just needs to be assigned to each developer.

  1. Assign a work item to a developer and track its progress.

  2. Developer writes code based on those work items. Submits the source codes then if necessary closes a work item when he or she is already finished, informing the project manager real time.

  3. Other developers writes code in parallel, with the ability to merge their work.

  4. Versioning of source codes. Each changes are saved in the server for later review or the eventual rollback just in case.

  5. Automatically translate these source codes to usable software.

  6. Test the software an file a “bug” task to a developer to be fixed.

    That 5 above, you can summarize that as in Work, Source Control and Build.

The above screen is the Home dashboard for the TFS Preview and it still reminds me back in the days where I had worked with TFS since the 2005 and that I have always wanted is a secure out-of-office access that enables me to assign work items, check bugs and also contribute on the source codes deliverables. Especially nowadays that I am running around all over places (or working from home and outside :p ).

In the advent of Cloud and the Microsoft Azure Services, why not put TFS in there! Azure is basically a Microsoft Cloud service and platform. These are always-on powerful servers, hosted in the cloud.


For more info about Azure, check this out

So instead of putting TFS instances in premise servers, we can now use TFS as a pay-per-use service hosted on Windows Azure. Yes, no server set-up needed.

And how did this new service made our lives basically easier and our team productive.

One. Collaboration. It gave us a system that enables us to work on one source. We felt the importance of collaboration thru one source when somebody cannot use TFS at the moment. That each and everytime he  /she will give a new source codes, I had to manually merge it and messes up everything. When he joined TFS, we already overcame the manual merge nuisance at last.

Two. We are all over places (ehem our homes, some coffee shop or anywhere where we can sit around and code). Gives us mobility. We can work anywhere as long as we have internet connection (even just for synching) – its like using your email client that you can compose your email replies on the go and just sync when there is an internet connection available.

Three. Service Resiliency. Lets just be realistic, powers go out, internet connections go bad. Server hardware crashes. We have seen a lot of these problems in our sprints and we never had to worry about the main source code and work item repository (TFS).



Four. Branching, Merging, Versioning.

Source code versioning is very important. It gives you a chance to go back in time to look for changes. Each change is group, thus called “Change Sets”. Each change set has a unique number associated with it and all other information like who submitted the change set, when was it done and ofcourse the ability to manage file conflicts – called merging. Sometimes two developer works on a single file, its like two person working on a single excel file or a word document, then merge their work later.



Branching is also a way to version the source code, having copies of the entire source code. Commonly used for back-ups, rollbacks and if different teams are using the code, like one branch is for Production Issues another branch is for Bug fixing then the build administrator merges the changes between the two branch. I

Let me share this scenario that has just happened last last week. Somebody deleted some code on the branch. He accidentally dragged a folder away and was deleted after he “submitted” his change set to the repository. “If we did not have TFS and I hadn’t branched last night, we are doomed”. But for now, I can sing:

“Branching, Merging, Com en-Versioning. Say it ain’t so, I will not go. Turn the lights off, carry me home. Na, na, na, na. Na, na, na, na, na, na, na, na, na, na, na”


Five. Continuous integration or CI. This is automatically “building” or “compiling” the current version of the source code and deploying it to the target system for testing. If the source code is not properly written, it would yield a “Compile or Build error” and cannot be deployed. When there is a compile error, we can file it as a bug and the developers can fix that as a part of their list of work. For it to automatically do CI, TFS needs to listen for a trigger, maybe a new source code submission, scheduled or a manually triggered event. Combination of these in a nutshell are called build definitions. You can even trigger a CI on the web 🙂




I have configured a lot of CI but configuring it on an SUR40 made it to the top of the coolest CI build that I did. Maybe I’ll blog about it later but for now I gotta get back there so TFS Guys at Microsoft, in behalf of our Ninja team thank you tfsservice!

Genesis Release 2.5

By Michael L. Coleman

In The Beginning the Project Manager created the Programming Staff. The Programming Staff was without form and structure. And the Project Manager said, "Let there be Organization"; and there was Organization. And the Project Manager saw that Organization was good; and the Project Manager separated the workers from the supervisors, and he called the supervisors — "Management", and he called the workers — "Exempt".

And the Project Manager said, "Let there be a mission in the midst of the Organization, and let it separate the workers, one from another." And the Project Manager created the mission and he called it — "The System". And the Project Manager separated those who were to benefit from The System from those who were to build it. And he called the former — "Users", and he called the latter — "Programmers".

And the Project Manager said, "Let all the Programmers in the Organization be gathered together into one place, and let a Chief Programmer be brought to lead them." And it was so. And the Project Manager saw that he was competent.

And the Project Manager said unto the Chief Programmer, "Create for me a schedule, so that I may look upon the schedule and know the Due Date." And the Chief Programmer went among his staff and consulted with them. And the  staff was divided into two parts; one part was called — "Analysts", and the other part was called "Application Programmers". And the Analysts went back to their desks and estimated, as was their custom. And it came to pass that each Analyst brought his estimate to the Chief Programmer, whereupon he collected them, summarized them, and drew a PERT Chart.

And the Chief Programmer went unto the Project Manager and presented to him the estimate, saying, "It shall take ten months." And the Project Manager was not pleased and said, "I have brought you up from the depths of the staff; you have not grasped the ‘Big Picture’." And the Project Manager hired consultants, and authorized overtime, and he said to the Chief Programmer, "Behold, see all that I have done! The Due Date will be in five months." The Chief Programmer was much impressed and went from before the Project Manager and proceeded to implement The System.

And the Chief Programmer sent his Analysts to the users and said, "Let Specifications be written." And there were meetings, and luncheons, and telephone calls. And the Specifications were written. And there was a Payday and the Happy Hour, one month. 

And the Chief Programmer examined the Specifications and saw that they were too ambitious. And he separated the mandatory features from the optional features; and he called the mandatory features — "Requirements", and he called the optional features — "Deferred", and the Users called him names. And the Chief Programmer gave the Specifications to the Analysts and said, "Let the Requirements be analyzed and let the Files be designed." And it was so. And the Chief Programmer said, "Let the Software Houses put forth their Salesmen, and let us have a Data Management System." And it was so. The Software Houses brought forth all manner of Salesmen who presented their packages, and claimed wondrous things for them, each according to his own file structure. And it came to pass that a Data Management System was selected; and the Chief Programmer saw that it was good. And there was a Payday and the Happy Hour, a second month.


And the Chief Programmer said, "Let the systems be divided into parts, and let each part be called a ‘Module’. And let programming teams be formed and let each be assigned to write a Module". And it was so. And the Chief Programmer created the programming teams with two levels, a greater and a lesser; and he called the greater the "Senior Programmers", and he called the lesser the "Junior Programmers". And he gave the greater dominion over the lesser. And the Chief Programmer saw it was good. And the Junior Programmers saw it differently. And there was a Payday and the Happy Hour, a third month.

And the Chief Programmer said, "Let the programming be started and let much overtime be consumed, for there is but two months left." And the Programmers, both the Senior and the Junior, were much afraid, and they strove to please the Chief Programmer. And they flowcharted, and they coded, each in his own fashion. And the Chief Programmer looked upon the work and liked it not. And the Chief Programmer said, "Let there be a Standard"; and there was a Standard. And the Programmers looked upon the Standard and liked it not. And there was a Payday and the Happy Hour, a forth month.

And the Chief Programmer said, "Let there be Progress Reports, so we can monitor and control"; and there were Progress Reports. And the Chief Programmer looked upon the Progress Reports and saw that the Due Date was not to be met. And the Chief Programmer arose, pressed his suit, shaved his beard, and went unto the Project Manager, and groveled. And the Chief Programmer pointed his fingers, and caused Blame to issue forth upon all manner of creatures who sold Hardware and Software. And the Chief Programmer asked for an Extension.

And the Project Manager was exceedingly angry, and cast doubts upon the Chief Programmer’s ancestry; and uttered a multitude of threats. But it came to pass that an Extension was granted; and the Chief Programmer took the Extension back to the programming teams, and there was much rejoicing. And the programming of the Modules was completed. And there was a Payday and the Happy Hour, a fifth month.

And the Chief Programmer said, "Let the Modules be integrated, one with another, so that System Testing may begin." And it was so. Two by two, the Modules were integrated, one with another. And great difficulties were experienced, and many hours of overtime were used, and many cups of coffee were consumed. And it came to pass that System Testing was completed. And there was a Payday and the Happy Hour, a sixth month.

Then the Chief Programmer did go to the Project Manager and said unto him, "Behold, I bring you good tidings, of a great joy which will come to all the Users; for on this day The System is completed." And suddenly there was with them a multitude of users praising the Chief Programmer and saying, "Glory be to The System in the highest, but can you make this one small change?"