Configuration management is the process of controlling changes and ensuring they are reviewed before they are made. A central focus of development models is to convert software development from a chaotic, unplanned activity to a controlled process. These models improve software development by establishing specific, measurable goals at each stage of development.
Regardless of how well development proceeds, changes that occur later in the process need to be implemented. For example, customers often introduce new requirements in the design stage, or performance problems discovered during development prompt a reevaluation of the design. You also might need to rewrite a section of code to correct a problem found in testing. Changes can affect any component of the project from the requirements and specification to the design, code, and tests. If you do not make these changes carefully, you can introduce new problems that can delay development or degrade quality.
After you set the project quality requirements, develop a process to deal with changes. This process is important for projects with multiple developers. As developers work on VIs, they need a method to collect and share their work. A simple method to deal with this is to establish a central source repository. If all the development computers are on the network, you can create a shared location that serves as a central source for development. When developers need to modify files, they can retrieve the files from this location. When developers complete their changes, they can return the files to this location.
Common files and areas of overlap introduce the potential for accidental loss of work. If two developers decide to work on the same VI at the same time, only one developer can work on the master copy. The other developer must compare the VIs to determine the differences and incorporate the changes into a new version. Avoid this situation by ensuring good communication among the developers. If each developer notifies the others when he needs to work on a specific VI, the others know not to work on that VI.
Using source control in LabVIEW is a good solution to the problem of sharing VIs and controlling access to avoid accidental loss of data. Source control makes it easy to set up shared software projects and to retrieve the latest files from a server. After you create a source control project, you can check out a file for development. Checking out a file marks it with your name so other developers know you are working on the file. If you want to modify a file, you can check out the file from source control, make changes, test the changes, and check the file back into source control. After you check in the file, the latest version is available to the development team. Another developer can check out the file to make further modifications.
|
Note��Source control integration in LabVIEW is available only with the Professional Development System. |
You must select, install, and configure a source control provider in order to use source control in a software project.
Refer to the KnowledgeBase for the most current list of third-party source control providers that work with LabVIEW.
Source management of all software project-related files is extremely important for developing quality software. Source management is a requirement for certification under existing quality standards, such as ISO 9000.
Refer to the Software Configuration Management and LabVIEW article on the NI Developer Zone website for more information on how to manage and control source code.
Sometimes you might need to retrieve an old version of a file. For example, you might change a file, check it in, and then realize you need to undo the change. You also might want to send a previous version of the software to a customer while you continue development. If the customer reports a problem, you can access a copy of the previous version of the software.
One way to access an old version of a file or project is to keep backup copies. However, unless you back up the file after every change, you do not have access to every version.
Source control provides a way to check in new versions of a file and access previous versions. Depending on how you configure the source control provider, the tools can store multiple versions of a file.
If you are managing a software project, it is important to monitor changes and track progress toward specific milestone objectives. You can use this information to determine problem areas of a project by identifying which components required many changes.
Source control providers maintain a log of all changes made to files and projects. When checking in a file, the provider prompts the developer to write a summary of the changes made. The provider adds this summary information to the log for that file.
You can view the history information for a file or for the system and generate reports that contain the summary information.
In addition, if you back up files at specific checkpoints, you can compare the latest version of a file with another version to verify changes.
You can use a sort option to organize items within a project. The sort option you select does not alter the organization of the project on disk, which allows you to merge and compare fewer changes when you submit the project to source control.
Large software projects can require a formal process for evaluation and approval each time a developer asks to make changes. A formal process can be too restrictive, so be selective when selecting the control mechanisms you introduce into the system.
Source control gives you a degree of control when making changes. You can track all changes, and you can configure a source control provider to maintain previous versions so you can undo changes if necessary. Some source control providers give you more options for controlling software change. For example, with Microsoft Visual SourceSafe, IBM Rational ClearCase, or Perforce, you can control which users can modify certain files and which users can only access those files. You also can control access so a user has privileges to modify a file only with the approval of the change request.