Overview

This article examines LabVIEW application development across groups of developers and provides recommendations for organizing and distributing code using tools such as the LabVIEW Project Explorer, Project Libraries and third-party source code control providers.

Table Of Contents

• Challenges of Group Development

• Recommendations for Group Development

• Source Code Contorl in LabVIEW

• Source Code Control Provider Support

• How Does Source Control Software Work?

• Integrating Source Control with LabVIEW

• Recommended LabVIEW Integration Settings

• Source Control Category

• Environment Options

• Moving Applications into Source Code Control

• Managing the Project File in Source Code Control

• Using Project Libraries to Distribute Code Modules

• Checking Files In and Out

• Process for Renaming Existing LabVIEW Files in Source Code Control

• Avoiding Code Collisions

• Configuring Graphical Merge for Use with Source Code Control

• VI Revision History

• Graphical Differencing

• Summary of Recommendations

• Frequently Asked Questions About Group Development

Challenges of Group Development

It is rare for a single engineer to work alone when developing a large, complex LabVIEW application. For the vast majority of applications, a team of developers or engineers will work together on the same set of code. However, without proper investment in infrastructure and planning, group development can introduce several pitfalls and inefficiencies.

Common high-level group development challenges include:

• Tracking and identifying changes to code

• Distributing code modules to development teams

• Detecting and resolving conflicting changes to source code

• Providing centralized access to all versions of code

• Integrating changes to the master code depot

It is nearly impossible to coordinate all modifications through simple electronic and verbal communication. In many cases, developers attempt ad hoc change control processes, whether they realize it or not, by saving multiple versions of a code module on disk as changes are made. However, this technique leads to confusion about the history of the code and adds even more time to the development cycle. For example, in the event that changes to a particular code module causes problems to occur when it is integrated into the overall project, time must be spent finding a previous version of the code that is still functions correctly, and remembering which changes were implemented between that version and the malfunctioning version.

Without a defined process for change control, bugs fixes get lost and mismanaged, the differences from one version to the next are not easily distinguishable, and changes made by one developer are not appropriately taken into account by the rest of the development team, leading to deficient code and inefficient development. Additionally, simultaneous editing of the same files by multiple developers is a common cause of lost work, as changes can result in overwritten data. Infrastructure to prevent these scenarios and notify developers that they need to combine or merge changes is critical.

Recommendations for Group Development

These recommendations will be discussed in greater detail in the following sections

• Use source code control during development to track and store files for all developers

• Integrate source code control in LabVIEW

• Develop the application framework and API for communication as early as possible

• Enforce documentation of changes in order to help developers track history

• Distribute large modules of code using Project Libraries

Source Code Control in LabVIEW

Managing large applications efficiently requires processes to deal with source code changes. Source code control (SCC) software offers a solution to the problem of sharing and controlling access to code by providing an additional layer of communication. Developers are required to inform the SCC software when they intend to modify specific files and describe changes upon any submission of new code. SCC software will store newly submitted code along with older versions for retrieval. This allows developers to see which files team members are modifying, and view prior versions of files.

Some of the high-level benefits of using source code control include:

• Provides central repository of code

• Detects and resolves code collisions

• Tracks behavior changes

• Identifies when changes are made and who made them

• Ensures everyone has latest copy of code

• Backup of different code versions

Controlling access to code also helps avoid accidental loss of data. Source control software tracks changes to code modules and facilitates file sharing among multiple users and software projects. Using source control software also encourages code reuse by making all code easily accessible to multiple developers.

Source control software helps ensure that changes to code are tracked over time and consistent among all members of a team. When source control is used within a team of developers, it also provides a great method for code reuse. All aspects of the project are kept in a central repository that is accessible by every member of the team.

Source Code Control Provider Support

National Instruments LabVIEW provides integration with industry-standard source control providers like Microsoft Visual SourceSafe, Perforce, Rational ClearCase, PVCS Version Manager, MKS Source Integrity and free, open-source software like CVS. This integration provides access to functionality in third-party source control providers within the LabVIEW environment. For more information on the various Source Control providers that can be integrated by LabVIEW, see the online Knowledge Base entitled Source Control Options in LabVIEW 8.

How Does Source Control Software Work?

Source control software maintains a centralized master copy of application files. When a developer decides to modify a file, he checks out the file from the source control software's repository to edit it. After the edits are complete, the developer checks in the new version of the file which becomes part of the master copy of the development project. Every time a file is checked in, the source control software prompts the user to describe the changes made. It is important that developers adequately describe the changes from a high-level that will affect the behavior of the code. This will be valuable later when viewing a list of revisions.

The source control software maintains this information so developers can clearly document the evolution of the each file in a project. The revision history of each piece of code is saved for the duration of the project in source control software, and modifications from one version to the next can be viewed by using graphical differencing, which will be discussed in greater detail later in this paper.

Integrating Source Control with LabVIEW

Once your source control provider of choice has been installed you can configure LabVIEW to allow developers to use source code control functionality from within the development environment. The goal of providing this integration is that developers can perform common tasks such as checking in and out of files and view the current status of files without launching a separate client or leaving the LabVIEW development environment. Some source code control providers may offer proprietary or advanced functionality that developers still need to go into the client to use; however, a majority of the time, they should be able to perform these operations from within LabVIEW.

Integration can be configured through the Tools > Source Control menu. This functionality is only available in the LabVIEW Professional Development System. Any source control provider installed on your computer and supported by LabVIEW will automatically populate the drop down menu, shown below in Figure 1.

Recommended LabVIEW Integration Settings

After selecting the source code control provider you'd like to use with LabVIEW, there are some settings in the options menu to be aware of.

Source Control Category

• Include hierarchy when adding files. This option is checked by default and is generally recommended. With this option enabled, adding a top-level VI to source code control will automatically prompt you to add all subVIs and dependencies of this file

• Exclude vi.lib. Modifications should almost never be made to the contents of this directory, as vi.lib contains the low-level VIs which are installed with LabVIEW. Therefore, adding these files to source code control is typically unnecessary, but can help demonstrate that no modifications were made.

Environment Options

• Treat read-only VIs as locked. If a file has not been checked out by a developer, the source code control provider typically sets it to read-only. Selecting this option will prevent developers from modifying or changing a VI if a file is read-only. It is generally recommended to select this option, but users will be forced to check out a file either way before modifications can be saved.

• Do not save automatic changes. Modifications to subVIs may prompt low-level changes to the binary of callers. Normally, LabVIEW will automatically make these changes and save the file; however, this can be disabled to avoid saving a revision of a VI that did not affect behavior.

Moving Applications into Source Code Control

Application organization and management is discussed in a separate paper, Best Practices for Managing NI LabVIEW Applications Using the Project Explorer, that outlines how to structure the hierarchy of files and how to migrate applications into the LabVIEW Project Explorer. Once source code control has been configured as described above and application files are in the Project Explorer, they can easily be added to source code control depot from the ‘Tools > Source Control Options' menu or by right clicking on them in the Project Explorer and selecting ‘Add to Source Code Control.'

Source code control can be used to manage any resource in your Project Explorer that has a corresponding file on the hard-drive. This includes VIs, documentation, images and the Project file. Requirements documents are frequently stored in source code control so that developers can track changes to documentation and view the history of revisions. This can be especially important for certified development practices, which often require developers to demonstrate that changes to requirements were covered by code. Tools like National Instrument's Requirements Gateway are useful for generating reports that indicate requirements coverage and provide traceability information.

To learn more about requirements management, read how to Map Requirements Documents to LabVIEW Code with NI Requirements Gateway.

If source code control is configured in an existing LabVIEW Project, the addition of any previously saved VI to the Project will prompt the user to add the new file to source code control. This prompt will only be displayed on existing files. New VIs do not have a corresponding file on disk until they are saved; therefore, they cannot be added to source code control. Adding files to a Project during development introduces new links and results in modifications to the Project file, which must be carefully managed and is discussed in greater detail in the next section.

Recommendations

• Develop the framework of your application before development to establish dependencies and links

• Add the top-level VI to source control first to automatically add all statically linked files

• Add the Project File to Source Code Control

Managing the Project File in Source Code Control

It is recommended that an application's Project file, or *.lvproj file, be stored in the source code control repository. This file contains links to physical resources in the Project Explorer using relative paths to the location of files, the settings specific to a particular project, and virtual items such as the build specifications. It is important that all developers have the most recent version of the *.lvproj file in order to ensure they have all the latest dependencies and resources.

Adding or renaming files in a Project will alter the contents of the *.lvproj file, which requires checking it out and submitting a new revision to the SCC provider. Since these changes affect all developers using the *.lvproj file, it is inadvisable to make any modifications during development. If changes must be made, they should only be made by one user at a time, and all other developers should get the latest revision of this file as soon as changes are complete. However, there are alternatives when this is not possible.

Ideally, the framework for the application is determined before development, and placeholders already exist for all future code and functionality. However, changes are sometimes required that force modifications to the framework and therefore to the contents of the *.lvproj file. These modifications can potentially affect linkages throughout the application and should not be taken lightly. The recommended practice is to make these modifications offline and outside of development - all files should be checked in to the depot and locked to prevent checking out. It is also important to ensure that new code is covered by requirements documents and that they describe why the files are being added.

Using Project Libraries to Distribute Code Modules

For large, complex LabVIEW applications it can be almost impossible to foresee all the code modules that will be needed to build low-level functionality. The use of Project Libraries addresses this problem because information about the contents of a Project Library is not stored in the *.lvproj file. For details on organizing large modules of code and distributing them to multiple developers using Project Libraries, consult Sharing Code with the LabVIEW Project Library.

However, if modifications are made to files inside the Project Library that are called by code outside of the Library, any links from callers will be modified and require updating. The use of APIs, or application programming interfaces, can mitigate this problem by establishing a set group of files that can be called by code outside the Project Library. Project Libraries allow you to set the access scopes of different files to either public or private. Files that are private can only be called from within the Project Library, and therefore cannot modify links outside the Project Library. The public files will provide the interface by which other code modules will execute code inside the Project Library.

Recommendations

• Store the Project File in Source Code Control

• Develop the application framework early to account for all future functionality

• All developers should have the latest copy of the Project File

• Establish APIs for communication between code modules and across Project Libraries

• Avoid modifying the contents of the Project File during development

• Use Project Libraries to create modules of code that can be modified without affecting the Project File

Checking Files In and Out

One of the most significant advantages to using source control in a development process is the ability to regulate and monitor modifications made to modules of code. When you need to make modifications to a particular piece of code, you must first ‘check out' the code module from a centralized repository. Check in and ‘check out' can be initiated from the Tools > Source Control menu, or by right clicking on the file(s) in the Project Explorer. The Project Explorer provides a method for organizing and maintaining all elements of a software design cycle in an intuitive and easy-to-use manner.

A red checkmark will appear in the Project Explorer next to files that have been checked out to you. In the event another programmer has already checked out the file a blue checkmark will appear. If the source code control provider allows both you and other developers to have the same file checked out simultaneously, this will be indicated using a blue and red checkmark next to the same file.

!file+status.png!

In order to manually update the status displayed in the Project Explorer of files in source code control, refresh the status by selecting Tools > Source Control options > Refresh Current Status. It is recommended that you do this before checking large groups of files out in order to see if any are currently in use by other developers.

Process for Renaming Existing LabVIEW Files in Source Code Control

Source code control stores the history of revisions associated with a file based upon the name of the VI. It is important that modifying the name of a VI be done according to a specific process in order to ensure the history of revisions is preserved. It is also important to ensure that all links to the files from dependencies are preserved within the LabVIEW application. Perform the following operation for statically linked files that are currently stored in source code control.

• Open the Project containing the application in LabVIEW - note that it is important that the Project be open and not just the file in order for LabVIEW to detect the rename operation

• Check all files out to a single development machine

• Perform the rename function from the source code control provide

• Return to LabVIEW and refresh the LabVIEW Project by pressing ‘F5.' The file you renamed will have an error next to it indicating that it has been renamed or removed from disk

• Right click on the file and select ‘Replace with'

• Find and select the new version of the file

• All links should be preserved and the history of revisions will still be associated with the VI

Avoiding Code Collisions

Most source control providers have an administrative option to lock files when they are checked out of the code repository. This ensures that only one set of changes is being applied to code at once, and therefore no conflicts will be introduced into a piece of code that has been touched by multiple developers. This is the easiest and most effective way to avoid code collisions. If it becomes necessary for multiple developers to make modifications to common files at the same time, it is possible to combine these changes. Source code control providers will store both copies of the file, thereby allowing developers to merge LabVIEW VIs. This can be done manually or automatically using the LabVIEW graphical merge functionality, which is discussed in greater detail in the next section of this paper.

Configuring Graphical Merge for Use with Source Code Control

Large application development often relies upon the process of merging a developer's modifications with a master copy of code. Developers often use code depots in source code control that are actually a branch of the master depot of files. When changes are complete, they may need to merge any updates that have been added to the master source code when integrating their modifications. This process can be performed manually, or it can be greatly expedited through the use of graphical merge. Graphical merge can be run from inside the development environment from the 'Tools' menu, or it can be configured to run when source code control providers detect a conflict that requires merging.

Source code control providers have built-in merging capabilities for text based files. However, if you attempt to merge LabVIEW VIs using text-based utilities, they will attempt to combine the binary data stored in the file. Source code control providers can be configured to call external applications upon the request of a merger between files of a certain file extension. In the case of LabVIEW VIs, the graphical merge functionality can be called externally and passed the appropriate parameters in order to perform the merger.

Calling graphical merge from an external application require the ability to pass parameters to the command line. In windows, the executable to be run is available at the following location: C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe.

There are four required parameters and one optional parameter, which must follow the call to the executable:

1. (Optional) Specifies path to the version of LabVIEW to use for the merge operation. If you do not supply this argument, the Merge VIs dialog box uses the following versions of LabVIEW by default:

2. Path to a copy of the VI from where you checked it out (Base VI).

3. Path to a copy the latest revision of the VI in source control (Theirs VI).

4. Path to the VI you edited (Yours VI).

5. Path to which to save the merged VI.

How this interaction is configured depends upon the source code control provider you're using, but to demonstrate, you could call this functionality from the command line as shown:

In Perforce, this functionality can be configured from the 'Settings >> Options' menu. Select 'Merge' in the categories and override the default for any file with a *.vi extension as shown.

Use of graphical merge from within the development environment is discussed in this article, Using Graphical Merge To Combine Individual LabVIEW VIs.

VI Revision History

While accessing source control software from LabVIEW, you can attach a description of the changes made to a file when you check it into source control. This information is maintained as the revision history for that file in the source control software. In this way, a chain of ownership can be followed for all of the various changes introduced to a project. Bugs and fixes can be easily tracked without requiring you to look at the actual code to determine what has been changed. A revision history can be maintained for not only LabVIEW VIs, but any file that has been added to your LabVIEW project. For example, a developer can use source control software to track changes made to feature specifications and other documents. You can see the revision history for any file by selecting Tools > Source Control > Show History from the file menu, as shown.

The revision history dialog that appears next is provided by the source control software you have configured. For example, Figure 6 shows the revision history for the project file Initialize.vi that is saved in a Visual Source Safe repository.

The dialogs will differ depending on your source control provider. In Visual Source Safe, there are a variety of additional options listed along the right hand side of the revision history. If you select Details while highlighting a particular revision, any comments entered by the developer upon check in are displayed along with date and time information, as shown in Figure 7.

Another feature in Visual Source Safe and other source control providers is the ability to retrieve older versions of the code module from the repository. Figure 8 shows this feature as it appears when Visual Source Safe is configured to be your source control provider. In the event that the current version of a code module no longer functions correctly, this feature allows you to obtain to an older, working version of the code.

Graphical Differencing

Software engineering practices often require developers to keep track and document changes when revising code. This help ensures that changes can be easily identified and that tests can be performed or re-run on code that has been modified.

Graphical differencing is available in LabVIEW to automate the process of comparing different versions of a file. This feature allows you to see a side by side comparison of VIs and highlights modifications. You can launch the graphical differencing feature in the Tools > Source Control menu or by selecting Show Differences from the right-click menu in the Project Explorer.

The VI currently in memory will be compared against the last version of that VI checked into the source control repository. Differences as minor as changes in position of a front panel control to major functionality additions will be highlighted for the user. For example, you can compare the version of Main.vi that is in memory with the Main.vi that was last checked in to the source control repository. The graphical differencing feature shows that several elements have been removed from a cluster by circling the difference in both block diagrams, as shown in Figure 10.

Note: The graphical differencing feature provided by LabVIEW has been tested extensively with Perforce and Microsoft Visual Source Safe source control providers and is officially supported by only these tools. If you are using a provider that does not support the integration of differencing, you can still run the comparison manually from the tools menu by selecting Compare VIs. You can also opt to compare entire hierarchies of files by selecting Compare VI Hierarchy.

Summary of Recommendations

Source control is essential in large projects with many files and teams working together on a software product. By using source control procedures into your software development cycle, you can increase your overall productivity and shorten implementation time for large projects. LabVIEW works within structured software engineering processes that require source control by integrating with your preferred source control provider.

• Enable integration in order to control generic SCC commands from within development environment

• Ensure ‘Add hierarchy is selected' to make sure that all subVIs are placed into source code control along with any callers

• Exclude the contents of vi.lib since you should not be developing in this location

• Select ‘treat real only files as locked' to prevent users from making modifications to files that are not checked out to them

• Project file should be added to SCC

• Determine how and when different sections of an application will call upon one another

• Design application framework and create placeholder VIs before beginning development

• Avoid making changes during development

• Minor changes should only be made by one developer at a time

• Do not make major changes while people have files checked out

• Use strict, regimented guidelines

• All users should sync to head revisions after changes are made. Getting the new project will show which files are missing

• Minimize changes required to links within an application using Project Libraries and APIs

Frequently Asked Questions About Group Development

1. Why was built-in source code control removed from LabVIEW?

National Instruments provides integration with third party source code control providers in order to allow developer to take advantage of providers that are the industry standard when providing configuration management and change control.

2. Does LabVIEW have any built-in source control tools that don't require 3rd party software?

Unlike previous versions of LabVIEW, LabVIEW 8.x does not include any built-in tools for source control. However, numerous third party options have been tested with LabVIEW 8.x, including some free open source options such as CVS (PushOK Windows client only).

3. Which version of LabVIEW integrates with third-party source control software?

The LabVIEW Professional Development System (PDS) provides the ability to integrate third-party source control software.

4. Is there a LabVIEW "merge" feature for resolving conflicts between different version of the same VI?

Yes. There is also a graphical differencing feature

5. What source control options do I have if I am using a Linux or Mac OS?

If you are running LabVIEW on either Linux or Mac, you must use Perforce as your source control provider to take access source control from within the LabVIEW environment. However, it is possible to use LabVIEW with any source control provider by simply accessing the source control functionality through the provider itself.

CLICK HERE TO VIEW THE WIKI ON SOURCE CODE CONTROL AND CONFIGURATION MANAGEMENT FOR LabVIEW

Elijah Kerry