This is another holdover from 2009. I’ve seen the look of terror in user’s eyes when the prospect of upgrading their huge, mission-critical applications comes up. This is one of the more challenging areas we face because of the sheer number of components, drivers, hardware, and third-party libraries that may be involved. Because of this, we’ve shifted our focus in general with the LabVIEW team to be less about new features and more about locking down the features we have to make them more solid, and more compatible between versions. Quality, performance, and compatibility are a primary focus in this timeframe.
Specificaly on upgrading, what are we doing? The first thing we are doing is getting our hands dirty – we are reaching out to customers to get involved in major upgrades so we can walk through the process ourselves. We’re doing this in a couple of ways:
1. Upgrade Assistance detailing the process and examples of the results.
We have had tremendous success providing upgrade assistance to several large accounts. Upgrade assistance consists of a LabVIEW Product Support Engineer (PSE) helping a user go through the process of upgrading their application to the latest version of LabVIEW. The key word here is “helping”. This is not intended to be a service provided by NI whereby we take your code and magically turn it into working code in the latest version. The PSE works with the user to walk them through the upgrade process, and expedites the resolution of any issues that are discovered. The process has typically taken two weeks elapsed time, start to finish. You get the benefit of learning how to approach an upgrade effectively and a direct contact within LabVIEW R&D to explore and remedy any problems. We get the experience of learning typical issues that LabVIEW users run into when upgrading, and each experience helps to shape our recommended upgrade process.
For a few of these engagements, we published case studies - one of them is 3,000 VIs and the other is 14,000 VIs.
2. Adding Real-World LabVIEW Code to Our Test Suite
We have recently instituted a process for adding real-world LabVIEW code to our automated test suite that runs on the daily builds of LabVIEW during our development process. Ideally, we are typically looking for code that meets a few criteria:
- Large (~1000 VIs or more)
- Can be separated from hardware
- Breadth of features (.NET, OOP, external code, RT, FPGA)
- Little to no 3rd party software components or issues
- Application at current release (or willing to upgrade to current release)
The process to incorporate code into our test suite requires some effort on the user’s side to assist us with getting it running in our environment. The code needs to either have existing automated tests, or some willingness on the user’s side to build some. Essentially, we need to be able to load, compile, build, and run the application. Running the application needs to produce a yes/no that indicates the application is functioning correctly (coverage can be very little to exhaustive).).
The application will be re-built and run daily in the new version of LabVIEW. Any issue that arises (failure to load a project or VI, broken VI, failure to build or deploy application, etc.) will have a Corrective Action Request (CAR) filed on it. The CAR will immediately be investigated and corrected. A report is provided to the user with changes, if any, that need to be made to the application so that it will run properly in the released version. This provides the user the opportunity to push back on us in case we underestimated the impact or pain of an issue that may not be resolved at release.
We need to establish a long-term relationship with each user that participates in this effort to improve efficiency, mostly to avoid the high cost of initial incorporation of a user application into our test suite. If interested in participating in this effort, please contact Jeff Phillips (jeffrey.phillips@ni.com
3. Daily builds
You may not have picked this up in the previous post, but with our renewed emphasis over the past few years on quality and performance, we have overhauled a lot of our internal development tools and processes. We’ve had consutants in from a number of companies including Microsoft to share best practices (I know what you’re thinking – but the Microsoft group that builds Visual Studio is pretty impressive. To hear them describe the number of test cases, builds, bug fixes, and code branches they manage in their development process is mind-boggling – but that’s another topic on Software Engineering). One commitment we are making is to have a daily build of the LabVIEW core stack ready for testing as we go through the development process. By instilling this discipline into the development process, we feel that not only will the development effort and beta versions will become more stable, but the end result of the release will be more stable and more compatible for users upgrading. This is a huge change in our development philosophy that was driven by our focus on quality based on discussions with our users.
Labview Software Update Issues
Ability to compare two sets of installations and have a difference list be generated.
Ability to compare the list of products for which you have legit activation codes with the list of products presently installed and activated.
These comparisons should be by product and by version numbers.
Differences should include links to updates on the web.
Ability to share a data file that contains the needed information with a remote user, such that they can then initiate the comparison.
Notes:
The activation codes that are sent in emails are difficult to reconcile with the activation manager as the names and version numbers do not always match.
Can some of these issues be fixed?