Update scripted.

.devcontainer/Dockerfile

@@ -6,15 +6,15 @@ FROM ubuntu:20.04
 ENV DEBIAN_FRONTEND=noninteractive
 
 # Terraform, providers and tflint versions
-ARG TERRAFORM_VERSION=1.0.0
-ARG AZURERM_VERSION=2.67.0
+ARG TERRAFORM_VERSION=1.0.4
+ARG AZURERM_VERSION=2.71.0
 ARG RANDOM_VERSION=3.1.0
-ARG TIME_VERSION=0.7.1
-ARG TFLINT_VERSION=0.29.1
-ARG TFLINT_AZURERM=0.10.1
+ARG TIME_VERSION=0.7.2
+ARG TFLINT_VERSION=0.30.0
+ARG TFLINT_AZURERM=0.11.0
 
 # Azure CLI version
-ARG AZURE_CLI_VERSION=2.25.0-1~focal
+ARG AZURE_CLI_VERSION=2.27.0-1~focal
 
 # Update distro (software-properties-common installs the add-apt-repository command)
 RUN apt-get update \

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+# This group is the default set of reviewers for PRs to main.
+@Azure/mission-lz-reviewers

.github/ISSUE_TEMPLATE/issue.md → .github/ISSUE_TEMPLATE/backlog_item.md

@@ -1,6 +1,6 @@
 ---
-name: Issue
-about: Use issues for planned work
+name: Backlog item
+about: Use backlog items for planned work
 title: ''
 labels: ''
 assignees: ''
@@ -15,4 +15,4 @@ assignees: ''
 
 **Acceptance Criteria**
 - 
--
+- 

.gitignore

@@ -9,6 +9,14 @@ terraform-provider-azurerm_v*
 terraform-provider-random_v*
 *.terraform.lock.hcl
 
+# Terraform logs
+crash.log
+
+# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
+# example: *tfplan*
+*plan*
+*.plan*
+
 # Setup config variables file
 mlz.config
 saca-hub.tfvars.json

CONTRIBUTING.md

@@ -15,56 +15,125 @@ or contact [[email protected]](mailto:[email protected]) with any addi
 
 Contributions come in many forms: submitting issues, writing code, and participating in discussions or questions.
 
-## Issues
+## Use of Third-party code
 
-This section describes the guidelines for submitting issues.
+Third-party code must include the associated license in the [`NOTICE`](NOTICE) file.
 
-### Issue Types
+## Contribution Process
 
-- Issue: Describe work that the team will do to enhance the product. Issues contain the elements of a user story:
-  - The title summarizes the work to be done.
-  - A benefit, reason, or outcome is entered as a single statement to describe why completing this issue adds value, and which role/persona will benefit.
-  - A label for the persona describing the person who will receive the benefit or outcome.
-  - A general description adds more context and details.
-  - Acceptance criteria describe specific details which tell us when the issue has been completed.
-- Question: Ask a question about how the system works, ask for feedback on an idea about how the system could work, or you ran into something unexpected and you want guidance.
-- Feature Request: Suggest a new idea for the project.
-- Bug: Report a defect.
+### Summary
 
-### Before You File
+We follow a [Kanban](https://en.wikipedia.org/wiki/Kanban_(development)) process. A product owner is responsible defining and prioritizing work in the product backlog. Each item in the backlog is a self-contained piece of work, finished to production quality and merged to the main branch. Releases are monthly and prioritization is set within releases. New priorities come from our stakeholders and from information we gather while doing the technical work.
 
-Before you file an issue, please check the following:
+### Why Kanban
 
-1. Check for existing issues
-    - Before you create a new issue, please do a search in [open issues](https://github.com/Azure/missionlz/issues) to see if the issue has already been filed.
-    - If you find your issue already exists, make comments and add your [reaction](https://github.com/blog/2119-add-reaction-to-pull-requests-issues-and-comments). Use a reaction:
-        - 👍 up-vote
-        - 👎 down-vote
-1. For bugs
-    - Have as much data as possible, including any logs or stack traces, environment, and versions.
-    - Steps to reproduce are essential for understanding how to duplicate the problem.
-    - Provide clarity on the expected result vs. the actual result.
+- Prioritization is dynamic: new priorities are discovered during each release and Kanban helps us quickly respond to changes.
+- Team member capacity is variable: our development capacity changes within each release.
+- Backlog items are self-contained: each item is a self-contained set of valuable changes that can be individually merged to the main branch.
+- Experienced team: we have a strong, experienced team that is able to execute Kanban in a disciplined way.
 
-### Pull Requests
+### Values
 
-All contributions come through pull requests (PRs). To submit a proposed change, we recommend following this workflow:
+- Openness: We welcome external input and collaboration with the community.
+- Transparency: All planned work is in public GitHub issues. Code is open source.
+- Empowerment: All team members make decisions on behalf of the product. Consultation with the rest of the team and the product owner is advised, but each team member decides what level of collaboration is required when making decisions about requirements, design, and architecture.
+- Continuous improvement: We continuously examine our process and implement intentional improvements based on empirical evidence.
+- Production quality: All code in the main branch is production quality. We assist each other through pair programming and pull request reviews.
 
-1. Make sure there's an issue (issue, bug, feature request) raised, which sets the expectations for the contribution you are about to make.
-1. Fork the relevant repo and create a new branch
-1. Create your change
-1. Update documentation where needed
-1. Commit the code to your branch
-1. Merge any additional changes from main into your branch and resolve any conflicts
-1. Create the PR and associate it with the relevent issue
-1. Wait for the CI process to finish and make sure all checks are green
-1. A maintainer of the project will be assigned and you can expect a review within a few days
+### Roles
 
-#### Use work-in-progress PRs for early feedback
+These roles demonstrate how we think about doing the work. A single person can operate with multiple roles. Roles can be part-time or full-time.
 
-A good way to communicate before investing too much time is to create a "Work-in-progress" PR and share it with your reviewers. The standard way of doing this is to add a "[WIP]" prefix in your PR's title and assign the **do-not-merge** label. This will let people looking at your PR know that it is not well baked yet.
+- Program manager: Responsible for the success of the product. Coordinates with external groups. Identifies product opportunities. Develops the product roadmap in collaboration with the rest of the team.
+- Product Owner: Responsible for the product backlog, architecture, and releases. Sometimes delegates decisions about the backlog and architecture to other team members, and always consults the team on key decisions. Communicates with external groups in collaboration with the program manager.
+- Team: Responsible for converting the product backlog into working code and documentation. Contributes to the product backlog, prioritization, architecture, and external communications.
+- Champion: Responsible for external communications and coaching to other groups. Funnels quality feedback into the product backlog. Contributes code and documentation to the product.
 
-### Use of Third-party code
+### Artifacts
 
-- Third-party code must include licenses.
+- Product backlog: The product backlog is defined using GitHub issues. [Issue templates](.github/ISSUE_TEMPLATE) are in the repo for [backlog items (new development) and bugs](https://github.com/Azure/missionlz/issues/new/choose). Issues are grouped into releases and prioritized within each release. See the [product owner process](#product-owner-process) for more details.
+- Monthly releases: Each release is defined using a GitHub project. GitHub projects are visible on the [Projects](https://github.com/Azure/missionlz/projects) tab of the GitHub site. One release is finished each month. We plan major themes for each release, but the actual content of a finished release depends on what is accomplished using our Kanban process.
+- Software increment: Each change to the software is implemented as a git commit to the main branch. GitHub pull requests are used to define and review each commit to main as a squashed merge (all changes combined into a single commit.) See the [development process](#development-process) for more details.
+
+### Events
+
+- Daily meeting: each day we meet to report what we did to move the project forward yesterday, what we plan to do the next day, and to identify any new impediments that must be removed.
+- Pair programming: we sometimes choose to work together on programming tasks.
+- Weekly backlog planning: the team meets for one hour each week to review changes to the backlog, review our current prioritization, and plan for future releases.
+- Monthly release retrospectives: in support of continuous improvement, we meet after each release to collaboratively decide on changes to our process based on our experience with the previous release.
+
+### Development Process
+
+#### Select a Backlog Item
+
+Team members select backlog items or bugs to develop. More than one member can work on a single issue, and pair programming and other collaboration is encouraged. Generally, issues that have higher priority should be done before lower priority issues, but any issue may be selected from the backlog by any team member.
+
+#### Create a Branch
+
+Issues that require code or documentation changes should be developed on a branch. These are guidelines for branching (not strict requirements):
+
+- The naming convention for branches is `<team member name or ID>/<one or two word description>`.
+- Every day, branches should be reverse integrated with main and updated from work in progress on the development machine.
+- Branches can be in a broken state.
+
+#### Develop
+
+Keep short dev/test/commit cycles within a branch, and create many commits per day. Keep the development branch in sync with main to avoid difficult merges. Stay in contact with teammates about what is changing so that merges do not conflict.
+
+#### Submit a PR
+
+Multiple PRs can be created for an issue, but there is usually a single pull request per issue. Optionally ask specific teammates for a review. Carefully follow the checklist in the PR template. Ensure that at least one GitHub issue is associated with the PR and assigned to the current release. When the PR is completed/closed, make sure the GitHub issue is also closed.
+
+A draft PR can be used to request feedback from the team.
+
+A [`CODEOWNERS`](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-code-owners) file defines the set of default reviewers for PRs to main.
+
+#### Review Other PRs
+
+When PRs are requested, review each change and run a full test deployment, specifically focused on the areas that have changed. Provide comments and feedback directly related to the PR.
+
+#### Ensure Quality
+
+The main branch is always production quality. The PR reviewer is responsible for ensuring that code merged to main meets our quality standards.
+
+### Product Owner Process
+
+#### Product Backlog
+
+The backlog is defined in the form of GitHub issues, including bugs and backlog items. Any team member or external stakeholder can author a backlog item. The product owner is responsible for ensuring that all backlog items in a release meet the standards of being ready for development. The standards include:
+
+- A clear title
+- A concise benefit/result/outcome that defines the benefit someone would receive when the issue is completed
+- An optional tag that defines who will benefit from the issue being completed
+- A detailed description that contains more context and may contain implementation details
+- A full list of acceptance criteria that clearly define when the issue is complete
+- Scope that is as small as possible and is also a complete and useful new feature for a stakeholder
+
+#### Triage
+
+The product owner is responsible for ensuring that each issue is fully triaged and is either closed or added to a release backlog. Triage with the team primarily happens at the weekly planning meeting and can also happen via GitHub as comments within an issue.
+
+When new issues are added to the GitHub issues list, the product owner ensures that a `needs triage` label is added so that the issue will be discussed in the next planning meeting.
+
+#### Weekly Planning Meeting
+
+The product owner sets the agenda for the meeting. The agenda includes:
+
+- New issues that need triage, usually selected by GitHub issues with a `needs triage` label.
+- Prioritization of new and existing issues within the current release. Items added or removed from the current release.
+- Changes to the themes of the current and future releases, and the scope of future releases.
+- Issues that are not currently in a release. (Filter the GitHub Issues list for issues not currently assigned to a project, i.e., `is:issue is:open no:project`).
+
+#### Backlog Prioritization
+
+The product owner is responsible for ensuring that the backlog items are prioritized within each release. Setting priority is a collaborative effort by the team and usually happens during the weekly planning meeting. Priority is defined by the stack rank order of the "To do" column in a release.
+
+#### Architecture
+
+The product owner is responsible for ensuring that enough architecture documentation exists for the development team and stakeholders. Developing the architecture is a collaborative effort with the rest of the team. Any team member may contribute to the architecture, and some issues may be added to the backlog for discovery and testing in order to determine the elements of the architecture.
+
+#### Release Definition
+
+The product owner defines the releases in the form of GitHub projects. One release is defined per month. Each release has one or more themes. The themes are reviewed and agreed upon by the team during the weekly planning meeting.
 
 **Thank You!** - Your contributions to open source, large or small, make projects like this possible. Thank you for taking the time to contribute.

NOTICE

@@ -1,61 +1,3 @@
 NOTICES
 
 This repository incorporates material as listed below or described in the code.
-
-Component: Bootstrap
-Bootstrap Reboot v4.5.3 (https://getbootstrap.com/)
-Copyright 2011-2020 The Bootstrap Authors
-Copyright 2011-2020 Twitter, Inc.
-Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE)
-Forked from Normalize.css, licensed MIT (https://github.com/necolas/normalize.css/blob/master/LICENSE.md)
-
-The MIT License (MIT)
-
-Copyright (c) 2011-2021 Twitter, Inc.
-Copyright (c) 2011-2021 The Bootstrap Authors
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.
-
-
-Component: jQuery v3.5.1 (c) JS Foundation and other contributors
-https://jquery.org/license 
-Note: The license text for jquery redirects to https://tldrlegal.com/license/mit-license#fulltext
-which is reproduced below, including placeholders for year and copyright holders.
-
-The MIT License (MIT)
-
-Copyright (c) <year> <copyright holders>
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
-copies of the Software, and to permit persons to whom the Software is 
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS 
-IN THE SOFTWARE.