Deploy Part 2 of 2

[swatts]

Hello LabVIEW Lovelies,

In the previous article I demonstrated how Deploy can be used to improve your software process, linked with version reporting,bug reporting and version control.

In this article I want to go under the hood of Deploy and show some of the nice touches you can add to your code, and more importantly how this makes you and your customers lives easier.

Starting with A on the image above we can see the current version of the software should be displayed, we sometimes link this to a dialog box that displays the VI documentation (where we store version info). I cannot emphasize enough how important this information is, similarly if you are doing realtime and FPGA projects stick a version number on these screens too. If you do an embedded system with communications make a command that tells you the version. You'll thank me at some point for nagging at you!

To dig out this information we use the code above at the start of the program, also notice that this is where we kick off the update API to check for changes every 5 seconds and this is wired into a user event.

Looking at the user event...

When a new version is available, the user event is fired that makes the new version button C visible and updates its tipstrip.

This leaves button B all this does is chuck up a webpage linked to our bug-reporting URL. More interesting is how these URLs are updated in Deploy so let's look at this.

We've touched on Constant VIs in the article on Rapid Debugging and Greg Payne talks about them in his blog, both of which were inspired by Fabiolas work. One  fundamental reason to why I like them is employed by Deploy to update URLs to the bug reporting and manifest URLs.

I added a custom page to the Deployment Configuration that allowed me to enter a Bug Report URL. Then in a custom step we use LabVIEW scripting to update the constant VI.

Perhaps at this late stage I should explain a little about the way Deploy allows customization. It uses dynamic loading to nice effect by taking numbered VIs in a customization directory and running them in order.

This is demonstrated quite nicely by showing it in the project window as below..

So here you can see that you can add custom steps and order them by changing the number. I squeezed the bug reporting URL into Step-100 and the other interesting step is Step-720-CommitSVN.

I wanted the changelog details to be made part of the Subversion commit message and also to be stored in the Main VIs documentation.

This is how it was done. I know it's a bit technical but I wanted to demonstrate how flexible this tool is and how you can bend it to your needs.

You may think this is a bit of a commercial break for Deploy but if I didn't think it was important I wouldn't go into writing. This type of tool, the integration of version control and the linking of project based constants into your code are extremely useful techniques that will add value to your code or maybe just make your life a little easier.

I'm all signed up for Geneva so if you are coming I'll see you there. Possibly might present.

I have a couple of articles on SMoRES and Re-use in the pipe-line but sadly I'll be spending a considerable amount of time preparing for my CLA-R exam instead (sigh!).

Lots of Love

Steve