In his post today, Marshall Fryman discsusses problems with shared development environment or workgroup development. Yes, it could be a complex problem which is rarelly addressed.
Note. Even though we are talking about Delphi here, it is really could be applied to any development environment.
Let look at the problem closer.
Problem
You have development environment with over dozen of development stations. You have similar development environment: versions of development tools used, locations, components. How to do easy update/upgrade in this environment and keep it up-to-date?
Solutions
1. Virtualization
My vote goes for virtualization – choose from VMWare, Microsoft VirtualPC or other solutions.
Then create base image which everyone would share, change your settings that anything which is user specific goes to his/her local drive instead of virtual image space. Yes, you would have to have some sort of unification, but it is true for any development environment nowadays.
If you go with Server editions of such products then it could be even easier since some of them could allow you maintain your own sessions without affecting main image.
Then make it through your virtual environment has a priority over your hardware so if you are in the development mode you would not really suffer penalty of virtualization. With new versions of Windows coming, I think it would become common and internally supported by default. For now you would have to do some maintenance.
2. “Virtualization”
The same name, but a way to achieve it is different. Instead of virtualizing a whole Windows environment, you do that for your Delphi environment only.
What does Delphi environment consists of?
- Delphi installation. We have to assume that everyone is on the same version. Best to have it in the same location, but it is not really necessary.
- Project source code. If you use any change management system, then you most likely already have everything in one place, and in the same folder structure. Projects are open from similar locations and exe/dcu files created in the same designated areas.
- Components, wizards. That could be a problem and this is where you really put “virtualization” in place.
Let’s think about it for a second. What does Delphi have to have to properly use custom components?
BPL, DCP, DCU, DFM/RES files location! IDE really does not care where code was compiled, but rather that components are properly registered and place to find all required files.
Keeping that in mind, let’s create proper infrastructure:
- Put everything in your source control system and have it in the same places on all machines. You could have BPL/DCP in the same folder with DCU files or in different locations. Also folder with DCU files should include all necessary DFM/RES files.
- In Delphi, add your new location for DCU to “Library Path” in IDE options, and your BPL/DCP location to “BPL/DCP output directory“.
- Do not add source location to a “Browsing path“, you do not want THIS shared code to be recompiled on individual machines. It will also prevent some “strange” errors when DCUs start to “walk around”.
- Then install all necessary Design time packages and you done.
How would upgrade process work?
Now it is easy. On your master computer update components, recompile if necessary, then check them into your source control system. Then, when necessary, before launching Delphi IDE your developers would get latest form depository, which will update all components and proper DCU/BPL/DCP.
It is rare when new components has to be reinstalled in Delphi since file/BPL structure is usually remain the same. Even when such maintenance is required it can be accomplished with simple .REG file deployed and applied to all machines. But it is rare situation.
Result – you now have fully maintainable, distributed development infrastructure.
Conclusion
Both scenario are result of my own experience in resolving an issue of handling workgroup environment and have been used in real life.
