Change is always inevitable and Changeset makes sense.


Let me start with a question for which I created a small poll. Please select an option to vote and then read further.

If you have not voted for option “You edit single file to resolve the issue/bug.” then you might be facing the pinch for a logical grouping of changes done to fix a bug. Team Foundation Server takes it to the level of logical grouping of changes.

Any piece of functionality we build for a software requires multiple files, until and unless you throw away all the design principles and write code in a single source file. Each and every activity in software development is a change, whether you add some files, delete some or edit some. Everything said above in TFS system needs to be checked-in, so when you see the check-in window it is visible as a pending change, ready to be committed to the source server (Pending Add, Pending Delete, Pending Edit).

Changeset is a logical grouping of the changes you do in source control, it is essentially a collection, what needs to be in the collection is ultimately controlled by the developer. So it is the responsibility of the developer to select the pending changes which would be eventually committed to the source control server.

image

Notice the Change types “edit”,and “add” in the screenshot above. These changes can now be checked-in as a set which we typically refer to as a “Changeset”. When I said that what contains inside a change set is controlled by developer earlier in this post, I meant that you can select which objects you want to check-in controlled by the checkbox besides every element in the above dialog.

Changeset is a linkable entity, meaning you can associate them as links with work items in TFS. Why is this important? The answer is simple, you never do any change in a software without a purpose when you consider the complete ALM picture. Each work item type, defines a purpose in the software development methodology. This helps us in understanding the purpose of source code changes, as to why we did a particular change, what was the intent behind and some more artefacts (like effort spent, developer comments, to which product functional area it corresponds to, to which release etc., will we dive into these details later in some future posts when we do a deep dive with work items).

Advertisements
This entry was posted in Agile Software Development and tagged , , , , , , , , on by .

About ssmantha

A Technologist and Evangelist, with more than 9 years of extensive experience in Microsoft and related Technologies. Working as Technical Solution Architect in To-Increase India since Sep 2006 Role - Technical Solution Architect responsible for creating cutting edge solutions in the Microsoft Dynamics Ax and NAV using .Net framework. Satya enjoys work involving implementation and integration of .NET and related Microsoft Technologies including Microsoft Dynamics AX and NAV, apart from playing around with new software technologies. He successfully built development tools which assists ERP teams to develop better solutions using Agile Practices. Using TFS 2010, Visual Studio 2010 he integrated the Development Processes with the Microsoft Dynamics Ax and NAV. By automating the development processes using the tools and technology, he was able to educate the practices, which in turn is helping people focus more on building innovative products rather than maintaining them. His latest work include a successful integration of ERP on Cloud, a pretty stable integration interface to a third party vendor. Another feather in his cap, automating TFS builds for Dynamics Suite of products on both AX and NAV. He is currently focusing on technologies surrounding ERP on cloud, Mobile Connectivity, XRM 2011 and many more. His areas of interest also include helping Development Teams work in a more structured way using Agile practices. Currently, Satya is working on the a Next-Generation of Business Integration Solutions for Microsoft Dynamics NAV 2013. Using industry proven architecture, he and his team are working on simplifying the domain of integration. Some key work areas he contributed on, Document Processor, Created a Data Model Mapping language and compiler working in tandem with XSLT transformation, and modular Integration Pipeline Architecture design.

2 thoughts on “Change is always inevitable and Changeset makes sense.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s