Share via

Choosing a host process type for a version control migration tool

  • Article

Last time I mentioned that we’d look at more architectural decisions for a migration tool – specifically what type of process it should be hosted in.

Some common arguments I hear for the various approaches are:

1) It should be written in a scripting language so the hosting process is the interpreter. This way I can make changes as necessary.

2) It should be a console application so it can run with needing user interaction. This way I can automate it in a script and have it run several migrations sequentially.

3) It should be a Windows application because I don’t want to have to deal with hand editing the configuration and so that I can see a UI that lets me know what is happening.

4) It should be a Windows service because I want to be able to manage it remotely and let it run without having to be logged on to a machine.

Each idea has merits.

Being able to easily change the tool to fit your needs is important. We will design tools to solve the problems we recognize and understand – but our customers may be facing slightly, or even vastly different, problems. Also a migration tool’s target audience is likely developers so it is not unlikely that they would be in a position to fix any bugs they encounter or extend the tool to meet their needs.

Being able to fully automate the migration is critical. A migration process can take days to finish. If we can make that faster by enabling a script to kick off the migration at 2am instead of needing to wait until a person can come in to click “Next” in the morning that is a really big deal.

Not having to hand-edit configuration is also important. It reduces the chance of typos. During migration a typo may mean the difference between being able to use the system you just spent tens of thousands of dollars on or having to send an email letting everyone know that a week of work has been lost.

Reporting and progress information is also very important. Especially when you are doing a multi-day migration and people want to know when they can start using the system.

Remote management and unattended execution are also very important. Leaving a machine running, even locked, may not be feasible in some organizations and remote management can be a great time and resource saver.

So the plan is to try and make everyone happy without creating a monster application that is everything to everyone and has 12 modes of operation.

I propose it should be a service application that has a console entry point (to aide in debugging and provide a simple command line interface for small migrations). Then release the source code, and document the configuration format extremely well. Finally have a real-time reporting system available to let people know exactly what has been done, what is being done, and what is left to do.

This obviously appeases the groups that want a console or service application. It should help the script-minded folks sleep better by sharing the source code (and makes the developer’s job a bit easier by allowing them to work in their development environment and language of choice) and while it does not directly help the folks who don’t want to hand-edit the configuration it does enable the creation of tools to do this at a later time. We’ve already seen that there are folks out there willing to take on this challenge for the benefit of everyone.

And of course by designing the system to decouple the hosting process from the rest of the system, and by releasing the source code and having good docs, if someone wants to change the process host to a Windows application later on they can.

Nothing Earth shattering today.

But I wanted to share the thought process that went into the decision.

Comments