|
Funny story
I was writing the requested mail yesterday, when it hit me, that most of what we want can be implemented as global subroutines and managed from central network "globals" repository.
The idea hasn't been completely thought through, but I think it will be an easier solution, then implementing the first mentioned process.
I'll try and explain my self:
The original thought was to make a utility/toolset which could handle merging of a collection of working production build scripts into a completely detailed and consolidated build script based on a main build script which holds references to first mentioned scripts as “VisBuildPro Project” call/project steps.
This was primarily for documentation and maintenance of the scripts. Because reading a script with 20 calls to other VBP scripts with no direct access to their content without doing a testrun, would become quite frustrating.
The setup at hand is several multisolution .Net products, build on several build machines, all by independently maintained buildscripts. This need to change to lower the administrative/maintenance overhead.
The project at hand is the streamlining of the build process and migration of these several large build scripts with very few VisBuildPro-calls to what ever structure provides the best solution for us.
The original thought was to create many smaller cross-product compatible scripts and a main-script pr product which only holds references to the smaller scripts by VisBuildPro-calls. These main-scripts would be fairly simple, as they aren’t to hold any other information then references, but also gave the problems mentioned with documentation and maintenance.
The project is still at and VERY early stage and I’m basically just collecting the initial information for the project specifications, but is it estimated that a “script-splitting” in some form or another, would improve consistency between applications, reduce the time need to implement new products and braches, improve the support for different build demands (nightly/release/continues integration) and make build process setup, test and responsibility mapping easier.
The original thought was to substitute each “VisBuildPro Project”-steps with a group step that have the name set with the name of the file called.
My question is now:
Does this sound like complete gibberish? As mentioned, this is still in early planning phase and I’m basically just throwing out ideas based on my very limited experience with VBP.
Is there another way that this kind of functionality is usually implemented
First and initial idea was the tool to merge several smaller script components in a main build script.
Would this provide the advantages we expect or is there and easier way around the problem that eliminates the need for a tool like that? The idea spawned from the apparent lack of an include function or something similar(?), which can include functionality from additional script and still make the information available from the GUI of the main script.
The second suggestion is where all functionality was imported as global subroutines/scripts/macros has been suggested, firstly this would require all build scripts to always include all subroutines (including a lot of unused functionality in even the most basic scripts) and the cost of this is unknown. Secondly, this requires all VBP installation to get the globals file locations changed, a feat I'm still not sure about how to do best. I was thinking along the line of implementing a prebuild step that loads a registry file holding the globals-path. This would require the machine to run the step at least once for the globals to be viewable from the GUI. I have seen the "Application.Steps.Load" function, but since (to the best of my knowledge) it is not possible to run code on load of the script, this would not provide any advantage over loading a registry file?
Can you recommend any changes or best praxis to the suggested strategies and your advise on what to choose?
I've send the Q pr mail as well, including license info, so you know I'm not a hack.
|