-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #283 from mitre/profile-dev-updates
profile dev updates
- Loading branch information
Showing
28 changed files
with
1,826 additions
and
1,189 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,42 +1,79 @@ | ||
--- | ||
order: 2 | ||
next: 03.md | ||
title: Repository Organization | ||
title: 2. Understanding Repository Organization | ||
author: Aaron Lippold | ||
--- | ||
|
||
## Repository Organization | ||
## Learning Objectives | ||
|
||
The repository and profile are organized into two primary branches: `main` and `TBD`. The repository has a set of `tags` representing iterative releases of the STIG from one Benchmark major version to the next. It also has a set of releases for fixes and updates to the profile between STIG Benchmark Releases. | ||
By the end of this section, you will: | ||
|
||
## Branches | ||
- Understand the branch strategy for STIG profiles | ||
- Learn about semantic versioning in the context of STIG releases | ||
- Know how to navigate tags and releases | ||
|
||
### `main` branch | ||
## Repository Structure Overview | ||
|
||
The `main` branch contains the most recent code for the profile. It may include bugs and is typically aligned with the latest patch release for the profile. This branch is primarily used for development and testing workflows for the various testing targets. For production validation, use the latest stable patch release. | ||
The InSpec profile repository should have a structured branching and tagging strategy to manage STIG profile versions and updates. This organizational strategy ensures reliable tracking of changes and stable releases for production use. | ||
|
||
### `v{x}r{xx}` branches | ||
## Branch Strategy | ||
|
||
The `v{x}r{xx}` branches represent the changes between releases of the benchmark. They align with the STIG releases for the Benchmark found at the DISA STIG [Document Library](https://public.cyber.mil/stigs/downloads/). | ||
Security developers and engineers should be putting actively developed changes and updates into feature branches. Once those feature branches have been completed and peer reviewed, they should be merged into the version branch for the respective guidance release. Once all required features, changes, bugfixes, etc. have been merged in, a release should be created - this means that the version branch should be merged into your main branch and a tag should be created. The main branch of the repository ought to be the latest, working version of the codebase. | ||
|
||
## Releases | ||
::: tip Branches are not releases | ||
Sometimes code ends up merged directly to the main branch - this is fine - the main branch is not a formal release. | ||
::: | ||
|
||
Releases use Semantic Versioning (SemVer), aligning with the STIG Benchmark versioning system of Major Version and Release. The SemVer patch number is used for updates, bug fixes, and code changes between STIG Benchmark Releases for the given product. STIG Benchmarks use a Version and Release tagging pattern `v{x}r{xx}` - like V1R12 - and we mirror that pattern in our SemVer releases. | ||
<table> | ||
<thead> | ||
<tr> | ||
<th></th> | ||
<th scope="col">Main Branch</th> | ||
<th scope="col">Version Branch (`v{x}r{xx}`)</th> | ||
</tr> | ||
</thead> | ||
<tbody> | ||
<tr> | ||
<th scope="row">Purpose</th> | ||
<td>Active development and testing</td> | ||
<td>Work-in-progress tracking a major STIG benchmark release</td> | ||
</tr> | ||
<tr> | ||
<th scope="row">Contains</th> | ||
<td>Latest code and patches</td> | ||
<td><p>Code that is becoming aligned to an official guidance release</p><p>DISA usually releases updates to STIGs on a quarterly basis. See the [DISA STIG Document Library](https://public.cyber.mil/stigs/downloads/).</p></td> | ||
</tr> | ||
<tr> | ||
<th scope="row">Example branch name</th> | ||
<td>`main` or `master`</td> | ||
<td>`v1r12` for Version 1, Release 12</td> | ||
</tr> | ||
</tbody> | ||
</table> | ||
|
||
## Tags | ||
## Version Control and Tagging Strategy | ||
|
||
### Current Tag | ||
### Tags | ||
|
||
We don't use a specific `current` or `latest` tag. The `current`/`latest` tag for the profile and repository will always be the latest major tag of the benchmark. For example, if `v1.12.3` is the latest Benchmark release from the STIG author, then the tag `v1.12` will point to the `v1.12.3` release of the code. | ||
#### Current Tag | ||
|
||
To use the current `main`, point directly to the GitHub repo. | ||
We do not recommend using a `current` or `latest` tag - if someone needs the latest and greatest, they can pull directly from the main branch of the repository. | ||
|
||
### Major Tags | ||
#### Major Tags | ||
|
||
Major tags point to the latest patch release of the benchmark. For example, `v1.3` and `v1.3.0` represent the first release of the Red Hat Enterprise Linux 8 STIG V1R3 Benchmark. The `v1.12.xx` tag(s) would represent the V1R12 Benchmark releases as we find bugs, fixes, or general improvements to the testing profile. This tag will point to its `v{x}r{xx}` counterpart. | ||
Major tags point to the latest patch releases of the benchmark. For example, `v1`, `v1.3`, and `v1.3.0` all should point at the same commit representing the first release of the Red Hat Enterprise Linux 8 STIG V1R3 Benchmark. The `v1.12.xx` tag(s) would represent the V1R12 Benchmark releases as we find bugs, fixes, or general improvements to the testing profile. | ||
|
||
## Patch Releases | ||
#### Patch Releases | ||
|
||
The latest patch release always points to the major release for the profile. | ||
|
||
For example, after releasing `v1.12.0`, we will point `v1.12` to that patch release: `v1.12.0`. When an issue is found, we will fix, tag, and release `v1.12.1`. We will then 'move' the `v1.12` tag so that it points to tag `v1.12.1`. This way, your pipelines can choose if they want to pin on a specific release of the InSpec profile or always run 'current'. | ||
For example, after releasing `v1.12.0`, we will point `v1.12` to that patch release: `v1.12.0`. When an issue is found, we will fix, tag, and release `v1.12.1`. We will then 'move' the `v1.12` tag so that it points to tag `v1.12.1`. This way, your pipelines can choose if they want to pin on a specific release of the InSpec profile or always run using the latest code on the main branch. | ||
|
||
### Semantic Versioning (SemVer) | ||
|
||
Format: `MAJOR.RELEASE.PATCH` | ||
|
||
- MAJOR: Matches STIG version | ||
- RELEASE: Matches STIG release | ||
- PATCH: Profile updates between STIG releases |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.