Can DQMH validation be used to update my custom modules?

[ThienEnthusiast]

I just recently updated to the latest DQMH version, and that had me use the validation option. It worked surprisingly well, and that got me thinking if it might be possible to use that feature for my custom Modules. My idea is to just have modules that I integrate into multiple different softwares, all created from the same source (a modul template). And once I make a change to the template that I want to implement everywhere (bug fixes and other improvements), I would like to do that the simplest way possible. 
So is the validiation tool a possible and/or good use for that, or am I simply better off to go to every software and load in the changed Template and make the necessary changes?

If any of you has other ideas to implement something along those lines, please share your input. I would love to hear alternative approaches, to essentially create some sort of standard.
Thank you for your input ^^

[shuttlefan]

I guess that's possible but I think that would involve a lot of the background scripting code that all that validation is based on, right?

[ThienEnthusiast]

Yea, I imagine so aswell, and I don't think my scripting skills are there ^^

Guess I will have to add updates manually to all my programms.

[Darren]

I don't quite understand the question. Are you asking if it's possible to add your own custom validation tests to the DQMH Validate Module tool? That isn't currently possible, but it is on the list of feature requests that the DQMH Consortium is considering for a future release.

If you're asking something else, can you provide more details, and perhaps a specific example of what you'd like to accomplish?

[ThienEnthusiast]

At our company we have many different testbenches for many different applications.

My goal is to streamline the process of implementing changes to any of the DQMH modules that are used in multiple projects.

For example we have built a DQMH module that deals with anything regarding to our ERP system, which is used in almost all of our testbench programms. Now if we find a bug in that module and implement a fix I am trying to figure out what the best way of distributing such a change would be. 

And the validation feature worked so smoothly for me, that I thought maybe this might be a good approach. Like we have to implement the changes only at the source, and then through scripting magic that can be easily applied with a few clicks to any of the projects that are built on said source. 

But maybe there is already a simple and reliable way to do so, and my train of thought is on the wrong track.

[Darren]

Thanks for the additional information. I agree with your assessment that DQMH Validator plugins would be the most streamlined way to accomplish your task. Hopefully the DQMH Consortium will prioritize this feature for a DQMH release soon.

In the meantime, you might consider writing a custom VI Analyzer test... you can have a test that identifies VIs based on name, and then scripts changes to those VIs. Since the VI Analyzer already provides all the scaffolding for identifying a folder/project of source code and running code across all those VIs, the only thing you have to worry about is writing the actual scripting VI (i.e. VI Analyzer test) that makes the changes. Note that the primary use case for the VI Analyzer is code inspection, but there's nothing stopping you from modifying the VI under test and then saving those modifications.

For an introduction to the VI Analyzer, see this video: https://bit.ly/vianalyzerintro

Towards the end of that video I describe how to write your own VI Analyzer test using the VI Analyzer Test Creator Wizard. Once you have created your own VI Analyzer test, you can learn how to install and use it here.

[joerg.hampel]

It sounds weird to me to roll out a bug fix to one of your reuse modules by "manually" reproducing the fix in all the software projects that use said module as a dependency. 

I would recommend a completely different approach: Maintain the generic, reusable ERP module in a separate repository and release it separately from all your applications. Then use that released version (source distribution, PPL, .VIP, ...) in your applications as a defined dependency, and update that dependency if and when bug fixes are available. 

[Darren]

Joerg is right... if this is truly a reuse module, then it should be distributed as such. The easiest way in my opinion is as a VIP.

I was envisioning that your code was more templatized, i.e. you had created some modules based off a template, some of that shared template code needed a bug fix, and you wanted to automate that fix. Basically the way DQMH works (it's a library template, and sometimes there are bug fixes to DQMH that need to be applied to all the modules based on that template).

So I guess the answer depends on whether you're dealing with templatized libraries (like DQMH modules that have unique differences) or reuse libraries (like OpenG).

[ThienEnthusiast]

My main goal is to find a good way to standardize project-creation and -maintainance for our company.

My starting point for that was, that I have created a "Prototyp" Project Template. It is based on DQMH-Modules, and has 2 Modules that are essentially always used for any of our testbenches and one "main" Module. The idea was to always individually program the main module to whichever purpose the testbench serves, but only implement minor changes to the 2 other modules and only if truelly necessary, and then even consider if it is useful to implement them always.

And if any other additional special functionalities are required, import a module template for that, or if none exists yet, create a prototype and if proven reliable make a template out of it, for future programs. 

With what I am playing around so far, seems decent, but maybe the approach Joerg suggested would be a better way. I have personally never implemented something like that, so I will have to do some reading. Would you have any suggestions where to start?

Or maybe the golden goose is a combination of both... 

[joerg.hampel]

I agree that both approaches have their place and it depends on your use case which one might be a better fit.

We do have our own HSE Flavour Scripting Tools for DQMH released on VIPM.io which allow us to convert a vanilla DQMH module into one that implements all the little bells and whistles that are part of our own DQMH flavour.

As for the whole topic of reuse code, releases and more... that's a very wide area of expertise. We have a lot of information collected in our Dokuwiki. The short URL pointing to our Way of Working is createbettersoftware.com - I think you should find at least enough information to get started.