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
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.
Notice 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.
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).