How often did you find yourself in a situation where you “just” wanted to implement a little change or have spent hours or even weeks on work into something just to recognize that you busted it somewhere on the way? How often did something suddenly break and your colleague tells you “I haven’t done anything! For sure!!! … Oh well, I just wanted to add/change/remove …” and he is 100% sure it can’t be the reason and undoing what he did (at least the parts he can still remember) doesn’t solve the issue?
Lucky if you have a backup. But even if you have one, how old is it? Do you also take continuous backups of all your custom scripts, your configuration files, or in case of MDT backups of your Task Sequences, customsettings.ini, scripts, etc?
I’m not a professional developer by any means, but let’s have a quick side look on Development as they need to tackle this problem as part of their job. In these days it’s already careless, maybe even grossly negligent for a Developer to not have a version control/source control solution in place. Simple backups aren’t enough. They need to keep track on changes, work on additional features without effecting the “core” application, support different implementations with custom changes but need to be able to merge changes from or to those slightly different projects. They often work with several Developers on the same project, on- and offline, etc.
But is this so different to parts of your daily work? Take MDT as an example. It often contains a bunch of custom scripts. You have configuration files like the customsettings.ini or the Task Sequences themselves that change quite regularly. You might have a couple Task Sequences and a couple Admins using MDT and implementing changes. You might have a well planned setup where you implement changes in a Development/Test environment first and then need to re-apply all changes done to your production environment.
I might be wrong but for me this sounds quite similar.
A Version Control System
You might roll your eyes now and think that’s to complicated. You might think I break a fly on the wheel. But I can tell you, it’s easier than it sounds. I will show you how you can set up a simple but effective solution within a few minutes. And as soon as you grasp some simple concepts it will make you more efficient and less error prone.
I will first cover some basics about Version Control Systems and then guide you through an installation of Subversion with a TortoiseSVN Client. And then show you some concepts/ideas how you can handle things like custom scripts or your changes to MDT. Why Subversion? Well, it’s very stable, widely used, available on many platforms, easy and simple to use. It ranges from very simple stuff like tracking configuration files up to hosting the development of huge projects with dozens of Developers. And the best part, it is free. TortoiseSVN is a very nice , almost ubiquitous and free Client that comes as a Shell extension. So you are using your Windows Explorer to keep track on your changes.
Some Fundamentals
There is a lot of information available about VCS. Both Subversion and Tortoise come with a quite extensive documentation and there are other sources as well. So it can become a bit overwhelming. At least it was for me. ;-)
Let’s pack this together a bit. As we want to start quite simple, there is no need to get into to much details. You will grasp this as soon as you start working and want to achieve more complicated stuff.
Repository
The Repository is simply the root of everything you would like to keep track of. You can have several repositories, e.g. one per Project or can have several projects within one repository. Think of it as as a container for everything you would like to have together. As you can imagine, there are some controversial opinions on how to structure your repository. Based on my limited view on this topic I followed the recommendation and just use one single repository for everything I do. That keeps the management requirements of it at a minimum.
Trunk/Branch/Tag
The Trunk is more or less your individual project. It’s the main source from the start of your project until the present.
A Branch is some kind of copy of your Trunk. Let’s say you want to implement a new feature (while feature is not limited to coding. Imagine changing your MDT Implementation from using AD Sites instead of Gateways for location discovery) but aren’t sure if it is working as desired or it simply requires huge changes on your main project. Or the implementation will take a lot of time while you need to ensure that the currently used version is still supported and other changes can be implemented. You could now just start implementing your changes and if it fails revert back to a version that was working.
Or you create a copy of your project, a branch, and apply all your changes on this branch. The kewl thing here is, that the Repository “knows” where it came from. So you are able to merge changes from your main project (the Trunk) into your branch to keep it up to date with global changes and also merge changes from the branch to the trunk if you have e.g. reached an important milestone or even finished the work on the branch so you can bring it back into the Trunk. Branching is also helpful if you have several implementations, maybe with some customizations. So you create a branch of your trunk and implement all the customizations necessary. And you can do this for every implementation you need. This way you keep them separated, you are able to support all the implementations individually but can also keep them updated with changes on your trunk if necessary.
A Tag is almost identical to a Branch. It’s also a copy of the Trunk, but see it as some kind of a snapshot at a specific point in time. By convention you don’t change anything after you have created a Tag. These “tagged” copies are typically created if you publish or release a version.
Working Copy
The Working Copy is simply what it says. It’s the copy you are currently working on. While the original files are hosted on the VCS Server (even if this is installed locally), you need to copy them to your computer to be able to work on them. This is also often called “Check out”. In the case of subversion, Check-Out really means taking a copy. It’s not locking the file(s) or marking them somehow. It’s just a copy. And at any time you can query the server for updates or publish your updated file(s) to the server (Commit). You can have multiple working copies at the same time and you can have them in separated folders somewhere on your hard drive. That’s actually what we can use when handling changes in MDT.
The Installation
Subversion
As both projects are open source, there are a couple sources you can get them from. For subversion I recommend the VisualSVN Server. It comes in a free version that gives us everything we need and even supports authentication of local and Active Directory Accounts. And it has one big advantage, especially if you are like me and don’t really know much about subversion itself. It’s quite easy to configure and manage, as it comes with it’s own management console. So no fiddling around with the command line. The installation itself is a typical “Next, Next, Finish”, so I spare the installation details. And everything can be changed/adjusted later if necessary.
TortoiseSVN
Get the Download here. Tortoise is available for 32 and 64 Bit Systems and in 32 different languages. It will install itself as a Shell extension. Again, “Next, Next, Finish” type of install will be sufficient for what we are going to do.
Initial configuration
After we have installed the subversion server, we need to configure at minimum two things to be able to start. As said, VisualSVN comes with a handy console to manage all the configuration aspects. So let’s open the VisualSVN Server Manager
Configure Users
We need to define who will be able to access our server. Well, actually we don’t really need to do this as on default simply “Everyone” will be able to access our repository, but its best practice to implement at least some minimum security at the beginning. Implementing this later can be come a bit difficult. On default VisualSVN is using the Subversion authentication so it’s maintaining its own users and groups. To create a new User either click on the “Create new User…” link on the main screen or right click on “Users” in the Tree structure on the left and choose “Create User…”
This will open up a dialog where you can enter username and password
The thing you need to be aware here is, that the password and(!) user name are case sensitive. Quite uncommon for us Windows folks ;-) The configured Users (and groups) can now be used to configure access to our server, the repository etc.
As mentioned, you can also use the Windows authentication. To do this, you can use the “Configure authentication options…” link from the main screen or you click on “Action – Properties” and choose the “Authentication” tab.
Here you can switch now between the different authentication methods.
Just be aware that the “Integrated Windows Authentication” is available only in the Enterprise version of the VisualSVN Server. But typing a Username and password the first time you connect to the repository shouldn’t be a tough deal ;-) If you are using Windows authentication you will recognize, that the “Users” and “Groups” entries from the console are gone. On default all members of the “Users” group have now access to the server. To change this click again on “Repositories” and then on “Properties”
I won’t dig any deeper into User management at this is a quite common task for all of us. Just wanted to show where and how to start.
Note: You might maybe want to give everyone Read-only access. But be aware that “Everyone” does not include anonymous access. If you need to allow anonymous access you should have a look on the article “Enhancing VisualSVN Server to allow anonymous access” by Rob Reynolds that based on an interesting article from Rick Strahl.
Set up the Repository
OK, we are now able to access our Server, time to set up our Repository. As mentioned earlier, there are a couple ways you can implement this. I personally try to keep it as simple as possible. So I use just one repository for all my work. You might consider creating a second one as some kind of sandbox. That’s quite helpful at the beginning to experiment on how all this works. Creating projects, branching, tagging, merging changes, etc. So let’s create two repositories. one “Main” and one “Sandbox”. You can create them either by using the “Create new repository…” from the main screen or right-click on “Repositories” and choose “Create New Repository…”
If you want VisualSVN can also create a default structure (trunk, branch, tags) for you. But as we are going to host several projects within our repository, we will add them later.
TortoiseSVN
I recommend a single change on the default configuration of Tortoise. To keep track on the changes Tortoise is storing them in a hidden folder. On default a “.svn” as a folder name. Some applications (including Visual Studio) doesn’t really like folders starting with a dot. So I recommend changing it to use “_svn” instead. to do this just right click on any folder, file, etc and choose Settings… from the TortoiseSVN context menu.
Then you will find an appropriate setting on the General tab of the settings.
Note: Be aware that this change should happen before(!) you have checked out any working copies. If not you would need to commit all changes done so far before changing this setting and then creating new working copies after you changed it. So best is, do it now ;-)
Ok, long post already so we will make a cut here. I (hope I) showed up the really simple concepts behind modern Version Control System and why it might make sense to not restrict their usage to “real” developers. Yes, they can be (and often are) incredibly more complex than what I showed but that comes due to the usage of them. That something a dozen Developers are working on for years shows up a bit more complex than the couple scripts or config files you and I are going to manage at the beginning should be obvious. It really is that simple so don’t fear to give it a try. You will actually drive the complexity, so it’s up to you.
In the next post we will go through some initial steps you will need for your daily work. We will use the VisualSVN Server and Tortoise Client to create Projects, import existing files into a new project, create a working copy of it, change scripts and commit those changes, create a branch, implement some changes and later merge it back into our main project, tag specific versions we want to publish etc.
After that we will have a look on how we can manage our custom scripts, manage changes on your configuration or even manage our complete Deployment solution (or at least parts of it) and keep them under control. Not sure if this is best practice but hey, it’s working. It’s saving me time and let me easily handle all my changes. We shouldn’t be afraid of porting best practices from one area to a different one.