TMT Configuration Management Process (Draft)
- Robert Karban
Configuration management is a system engineering process that allows for a system to maintain consistency in product performance, functions, and attributes such as requirements, design, and operational information.
1. Model-Centric Use Cases
a. One of the model-centric use cases is the entire model contributes to continuous integration. In this case, model elements will have their own version where they are the continuous integration of the model. The model can then use other models that become continuously integrated.
b. The model location can be in one of three places. The location can be found either on Github, Teamwork Cloud, or OpenMBEE/Model Management System (MMS).
2. Configuration Management Modeling Plan
An example of the configuration management modeling plan can be developed by adopting the GitFlow model for managing changes and branches. In this case there is a trunk/master branch followed by a develop and feature branch (e.g., (FEATURE_NAME) branch). It can be noted that the feature branches follow the same naming convention with the "feature/" prefix (e.g. feature/documentation). The feature branches are then merged to the develop branch. The develop branch is the only branch that is merged to the master branch.
3. Configuration Management Process Overview
The processes for how the configuration management process is completed is through Gitflow where you can make local merges. A specific use case for this workflow overview is where Thirty Meter Telescope (TMT) has a case where a systems engineer cannot access JPL's Teamwork Cloud. In this case the workflow is managed by:
Committing the model to GitHub
Accessing branches on GitHub without access to Teamwork Cloud
Systems engineer works on their own branch
Someone with access to Teamwork Cloud pulls these changes and pushes them to Teamwork Cloud to the same branch
4. Configuration Management Supplemental Details
4.1. Change Requests
Change requests are handled and reviewed when a feature branch is going to be merged to develop and through consistent branches on various platforms.
4.2. Viewing the Recommended Changes as a Reviewer
a. The reviewer can view the recommended changes before a merge diff is done.
b. The reviewer can also view recommended changes using Lemontree web and the Lemontree plugin. Lemontree is a promising tool that has passed initial testing and still being fully evaluated. The diff can happen locally with the plugin and on the web for Teamwork Cloud branches.
c. Lastly, the reviewer can view changes in OpenMBEE View Editor, which allows for viewing changes between branches.
4.3. Changes to the Model/Product
The best practice when making changes to the model/product, it is advisable to utilize feature branching in order to test and build out changes before committing to the model.
4.4. Tracking Changes
Changes in the model can be tracked via the Teamwork Cloud, through GitHub, and on the OpenMBEE Model Management System (MMS), as well as View Editor.
4.5. Preferred Version Control Mechanism
The preferred version control mechanisms used are Teamwork Cloud, GitHub, and the OpenMBEE Model Management System (MMS), as well as View Editor.
4.6. Version Control Mechanisms Used for Model Products
The version control mechanisms used for products that were derived from the model were OpenMBEE View Editor and OpenMBEE Model Management System (MMS).
4.7. Tying Product Generated Meta-Data to MagicDraw
To see if the meta-data in generated products tie back to MagicDraw it is necessary to look at the element level version control in the Model Management System (MMS) of the various model elements. To show how this ties back to the model, the engineering documents cross reference specific versions of the model elements. However, there is no stored information on the MagicDraw version used to create the meta-data, which is something that should be evaluated to be implemented.
{"enableNumbering":true}