This project will show the steps it takes to develop features following a DO-178 process along with going through a Problem Report process
Note - All changes shall be associated to a feature issue or a problem report issue
- Its recommended to call out the issue number within pull request comment thread or description when creating. This helps easily show the link between the review and the feature issue
- In the commit changes add tags to help identify what artifact is being updated tags could be {SLR, HLR, SSD, LLR, CODE, TC, TP}. I could see multiple in a commit, but I would recommend splitting that commit to separate out
- In commit comment that’s updating per an informal review discussion consider adding the commit hash were discussion occurred. This allows a nice link to show what drove the change Here is an example
- Create an issue - This will be the change authorization and overview of what needs to be done for a particular feature. For an example I will create an feature issue that will add the bound function
- For organizational purposes we can use milestones to organize a set of feature issues. For example, if we are working on a math library we might want to have separate feature issue to add in cos, sin, ceiling, floor, etc. The milestone will be the container to help track all of the issues
- Create branch to handle feature development - This could be analogous to a team stream
- Creation of system requirements/high level requirements - This will consist of the creation and informal review(s)
- Creation of software design - This will consist of the creation and informal review(s)
- Creation of low level requirements - This will consist of the creation and informal review(s)
- Creation of software - This will consist of the creation and informal review(s)
- Creation of test cases - This will consist of the creation and informal review(s)
- Creation of test procedures - This will consist of the creation and informal review(s)
- Formal review of feature - This review will cover all the changes that occurred within this feature issue
I would recommend using Gitlab Flow branching mechanism. This uses a branch, do development, merge changes back into mainline. When it comes to needing releases, then we would create release branches. They call this pre-production branch, and production branch which would be a branch off pre-production.
Ideally feature branches wouldn’t be merged into the mainline until ready but since our teams are broken up into functional teams there are dependencies. That would mean a few different process to accomplish integrated features
- Functional teams that have feature branches would need to sync between their branches to insure proper integration. Once integration is done N teams would merge their branches into the master/trunk
- Functional teams merge to master/trunk, do the integration and when they find problems on their side then updates would happen on their feature branch and remerge with master/trunk
- Functional teams merge what they have to master/trunk and then re-branch to handle integration changes
- Functional teams work on 1 feature branch and when completed and integrated then its merged into the master/trunk
The 2nd option is what we are use to and probably easily adaptable to the teams.
I don’t think we should really be changing the problem report process
- Problem Report has been created - Using a template that automatically gets populated when issue created
- Analysis occurs - Engineer evaluates that this is a real problem and what might need to be fixed
- CCB overviews problem report - This evaluates the PR and priorities vs others
- PR Opened - Work occurs on fixing the PR. This shall be done in a separate branch.
- PR Fixed - This is where the developer thinks the PR is ready to be reviewed.
- PR Verified - PR has be marked verified and ready for CCB approval on closer
- PR Closed - CCB has approved the changes