OPC Data Client - Application Upgrade Considerations & Best Practices

Planning

• What change management and and development best practices does your company have? Have you asked? You should incorporate those into your process. 
• Did you write the application?
  • Yes - then have you documented at a high level, how you use various tools, so that you can follow a consistent review each time? If you were no longer working in this position, would someone else be able to pickup and maintain the application? If not maybe now is a good time to start. 
  • No - then have you done a thorough code review to understand the application? Maybe now is that time to do that, and document it, if you were left nothing. 
    • Targeting - OS, .NET, etc. 
    • External library dependencies
    • Methods and Namespaces used
    • Overall structure and theory of operation? 
• Review release notes and system requirements for all affected tools you are updating
  • OPC Data Client Release Notes History
  • OPC Data Client System Requirements
• Review any release specific changes that could have significant impact
  • With OPC Data Client, always look at the Targeted, Packaging, Component Refactoring sections of the release notes for possible breaking changes 
  • We have a list of past major changes for OPC Data Client that you can review 
  • Make a list for yourself for your application for use in implementation. 
• Does your planned update of a component also require you to move to a newer version of your compiler or a newer operating system? Does that affect other tools? 
• Do you have a source code repository such as Subversion, Git, or other setup? If not do you store multiple copies of your source with them backed up off your PC, so that you can revert back if required? You must be doing something before you plan any toolset upgrade, to avoid ending up stuck and not able to revert. 
• How do you install your project for your customer? Do you have an installer, or do you distribute files to them with instructions for placement, or do you upgrade their installations for them? 

Implementation

• Always work off a copy of your last known tested source code for your application. Never work directly on your backup
• Consider the list you made in planning. If you had no major or breaking changes, implementation may be relatively easy.
• The more complex the changes, the more you may want to do some testing outside of your codebase to understand change method calls, etc. 
• When possible take changes one step at a time, performing logical tests after each change to confirm things are working before moving to the next step. We know this may not always be possible, but test early, test often is a key best practice. 
• If you run into an issue, try and make a simple, bare bones blank application that uses the affected function(s) and test that to isolate the issue and then compare to your application. If you needed to come to our product support or professional services team for help you would need to have that test rig application. 

Testing & Rollout

• We cannot repeat enough how important it is to test in your controlled environment during and after changes. 
• How far your testing goes is a function of knowing your application. If there were only 1 method change that you had to make, then you only need to test areas of your application affected by that change. 
• If you have upgraded your targeting, such as .NET version, and/or compiler such as Visual Studio, you should plan on more thorough testing
• Do a pre-ship, pre-release TEST on a clean machine or virtual!  It is very easy to have things work on your computer as the developer and end up with different results on customer machines. Virtualization makes it easier to maintain a test environment so that you can take your installer, or deployment procedure, and test it before you send it to your customer or send a co-worker into the field to install the update.
• Only ship to your customer when you are confident of your ability to deploy in your controlled environment.