Developer Isolation and Team Development


Software development is a team task, meaning there are multiple people are working on a same code-base which collectively results in a piece of software or functionality. What if we share common runtimes and also common code-base? The situation can be quite disastrous if something goes wrong.  In our previous post “The importance of Version Control”, Ron raised some questions in mind of a developer, if we do share a common code-base.

The Visual Studio development environment provides us with a kind of localized runtime specific to a machine.  Developers can now change their code and run on their machine to test and see if their code is working correctly or not. However, this is still not sufficient. In case of team development we require more. We need to share our code-base also. We are talking about “Parallel Development” here.

Parallel development allows multiple individuals to work in isolation, safely developing same, or different parts and versions of a project at the same time. 1

To understand a bit more of Developer Isolation, let’s see how a typical .NET Project works under source control. When you first create a project in .NET it is not source controlled. To do so  you need to add the solution to source control

 image

Once your solution is under source control it is accessible to all the developers. They simply need to connect to the respective Team Project and associate the sources to their what is called a workspace.  There are two types of workspaces, public workspaces and private workspaces. For simplicity we use private workspaces which are mapped to each individuals working folder (folder mapping). Files in this local folder are all marked as read-only so that you don’t accidently edit them. Each file now has two versions, a local version and a server version. The server version is the what we consider as the “Latest stable version”. So when you edit it you are isolated from other developer’s changes since you are working on your local copy of the sources. This is how it looks in Solution Explorer when you have a source controlled solution.

imageNotice the locks besides each version controlled item, it signifies that the file or the source is currently not editable. In order to edit the file you need to do a checkout, right-click on the file you want to edit (let’s say Class1.cs) and click on “Checkout for Edit…”, there would be a small red tick mark besides the file suggesting you can now edit it.

image image

Now once your file is checked-out you can safely edit it and be rest assured that it will not conflict with other developer’s changes who might see that you have locked it. There are some advanced tricks here, like multiple checkouts, but for simplicity we would take them later.

One more important consideration is Isolation of Runtime. Visual Studio by default provides runtime isolation, which enables multiple developers to work on their individual memory space or you can say execution space. So when you build your project your changes are still local and when you run them they are in your local system’s memory space. This level of isolation makes sure that what you changed is reflected in your runtime without adding to confusion with other changes which are not yours and not committed (checked-in , where your version goes to server which is shared and available to all).

In Version Control Systems, it always pays to share what is really common, in the case above you see the sources, what not makes sense is to share runtime which should be obvious by now.

In case of Microsoft Dynamics NAV, we missed it. We noticed multiple developers working on same code base and usually same database and the risks were obvious. Overwriting changes, deletions of objects which seems irrelevant to one developer at first glance etc. Isolation of the development environment was a big challenge for us. Luckily, NAV runtime is quite light-weight so we can bring that into our systems, along with the database. So what’s left, objects (just like sources above). Since these are the real entities we play around during our development. These need to be properly version controlled and tracked. Also we needed to make sure that we every change it is synchronized (i.e. our local database has the code imported and compiled properly).

1 http://msdn.microsoft.com/en-us/library/aa290068(v=vs.71).aspx

Advertisements
This entry was posted in Agile Software Development 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.

4 thoughts on “Developer Isolation and Team Development

  1. Pingback: Reversibility (Undo Pending Changes) | Agile.NAV

  2. Pingback: Developer Isolation and Team Development | Pardaan.com

  3. Pingback: Reversibility (Undo Pending Changes) - Agile.NAV | Agile Software Development for Microsoft Dynamics NAV - NAV Technical Blogs - Microsoft Dynamics Community

  4. Pingback: Poll: What is your Microsoft Dynamics NAV Development Environment? - Agile.NAV | Agile Software Development for Microsoft Dynamics NAV - NAV Technical Blogs - Microsoft Dynamics Community

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