Commit f2f44b0d authored by Nick Nguyen's avatar Nick Nguyen Committed by Nitin Kumar Garg
Browse files

Move /infrastructure product and platform pages to /infrastructure-platforms

parent d77f5308
Loading
Loading
Loading
Loading
+0 −1
Original line number Diff line number Diff line
@@ -188,7 +188,6 @@
/content/handbook/engineering/infrastructure-platforms/gitlab-delivery/distribution/ @marin @denisra @mbursi
/content/handbook/engineering/infrastructure-platforms/emergency-change-processes.md @marin @bill_staples
/content/handbook/engineering/infrastructure-platforms/incident-management/ @dawsmith @rnienaber @marin @sabrams @jtoto-gtl
/content/handbook/engineering/infrastructure/platforms/ @marin @rnienaber @amyphillips
/content/handbook/engineering/infrastructure-platforms/service-maturity-model.md @rnienaber @marin @bill_staples
/content/handbook/engineering/infrastructure/team/ @marin
/content/handbook/engineering/infrastructure-platforms/andrew-newdigate.md @andrewn
+1 −1
Original line number Diff line number Diff line
@@ -1015,7 +1015,7 @@ Cloud Spanner uses Multi-Version Concurrency Control (MVCC), storing all version

1. How and where the Topology Service will be deployed?

    We will use [Runway](../../../infrastructure/platforms/tools/runway/),
    We will use [Runway](../../../infrastructure-platforms/tools/runway/),
    and configure Topology Service to use [Spanner](https://cloud.google.com/spanner) for data storage.

1. How Topology Service handle regions?
+1 −1
Original line number Diff line number Diff line
@@ -18,7 +18,7 @@ Initially, we plan to mitigate the costs of remote data access by scanning on a

[Summarized from the original spike discussion](https://gitlab.com/groups/gitlab-org/-/epics/10283#note_1888852733):

As covered in [the epic's technical needs](https://gitlab.com/groups/gitlab-org/-/epics/10283#technicalplatform-needs) we want as few installation steps and dependencies as possible; a goal that is most easily achieved by hosted, remote scanning solutions. It also fits GitLab's existing deployment paradigms and evolving best practices around [Project Runway](../../../../infrastructure/platforms/tools/runway/) and the [AI Gateway](../../../architecture/design-documents/ai_gateway/) which already provide pathways to realise service integrations. In contrast, for local scanning we do not have these pathways yet.
As covered in [the epic's technical needs](https://gitlab.com/groups/gitlab-org/-/epics/10283#technicalplatform-needs) we want as few installation steps and dependencies as possible; a goal that is most easily achieved by hosted, remote scanning solutions. It also fits GitLab's existing deployment paradigms and evolving best practices around [Project Runway](../../../../infrastructure-platforms/tools/runway/) and the [AI Gateway](../../../architecture/design-documents/ai_gateway/) which already provide pathways to realise service integrations. In contrast, for local scanning we do not have these pathways yet.

Both the spike and previous technical discovery assumed we must retain ephemeral environments (modeling our CI builds), so we maintained this constraint.

+6 −6
Original line number Diff line number Diff line
@@ -278,11 +278,11 @@ The Engineering Leads for each Stage, along with their Product Managers, hold we

**Weekly Schedule**

- Wednesday (or depending what day is configured for the team): each Epic DRI will receive a [note that mentions them for a status update about updating progress](/handbook/engineering/infrastructure/platforms/project-management/#status-updates-on-project-epics). Keep updates short, and include:
- Wednesday (or depending what day is configured for the team): each Epic DRI will receive a [note that mentions them for a status update about updating progress](/handbook/engineering/infrastructure-platforms/project-management/#status-updates-on-project-epics). Keep updates short, and include:
  - New achievements from a high-level, business-oriented point of view. Graphs, demos, visualizations are also welcome.
  - Changes to risks, blockers, timelines, scope, and whether you need help or surfacing FYI
  - New key decisions made
  - Projects that are completed, including a [closing summary highlight in the epic description](/handbook/engineering/infrastructure/platforms/project-management/#when-a-project-is-finished). Leave the epic open, with the In Progress label. These epics will be closed during the Grand Reviews.
- Projects that are completed, including a [closing summary highlight in the epic description](/handbook/engineering/infrastructure-platforms/project-management/#when-a-project-is-finished). Leave the epic open, with the In Progress label. These epics will be closed during the Grand Reviews.
- Thursday: Group Level Reviews conducted and added as threads in [Infrastructure Platforms Top Level epic](https://gitlab.com/groups/gitlab-com/-/epics/2115) (see [example](https://gitlab.com/groups/gitlab-com/-/epics/2115#note_2197983622))
  - Data Access: run by the Data Access Acting Sr. EM and the Group PM
  - Tenant Scale: run by the Tenant Scale Sr. EM and Group PM
@@ -340,20 +340,20 @@ Agents responsible for handling these issues are defined in a JSON file, which s

### Project and Backlog Management

We use epics and issues to manage our work. [Our project management process](/handbook/engineering/infrastructure/platforms/project-management/) is shared between all teams in SaaS Plaforms.
We use epics and issues to manage our work. [Our project management process](/handbook/engineering/infrastructure-platforms/project-management/) is shared between all teams in SaaS Plaforms.

### Tools

The Platforms section builds and maintains various tools to help deploy, operate and monitor our SaaS platforms. You can view a list of these tools in the [Platforms Tools Index](/handbook/engineering/infrastructure/platforms/tools/).
The Platforms section builds and maintains various tools to help deploy, operate and monitor our SaaS platforms. You can view a list of these tools in the [Platforms Tools Index](/handbook/engineering/infrastructure-platforms/tools/).

### OKR

We use objective and key results to set goals in alignment with [OKRs at GitLab](/handbook/company/okrs/).
[Our OKR process](/handbook/engineering/infrastructure/platforms/okrs/) is shared between all teams in Saas Platforms.
[Our OKR process](/handbook/engineering/infrastructure-platforms/okrs/) is shared between all teams in Saas Platforms.

### Hiring and Interviewing

[Our hiring process](/handbook/engineering/infrastructure/platforms/hiring/) is shared between all teams in Infrastructure Plaforms.
[Our hiring process](/handbook/engineering/infrastructure-platforms/hiring/) is shared between all teams in Infrastructure Plaforms.

This [Infrastructure Platforms Interviewing Guide](/handbook/hiring/interviewing/infrastructure-interview/) offers more detail on some of our regular openings, interview process and other useful information related to applying to jobs with us. More information on our current openings can be found on the [careers page](https://about.gitlab.com/jobs/).

+4 −4
Original line number Diff line number Diff line
@@ -67,11 +67,11 @@ Create issues to request support through the RFH process below. This will allow

## Project Management

All work is tracked in epics and issues. We follow the [The Infrastructure Platforms Project Management processes](/handbook/engineering/infrastructure/platforms/project-management/)
All work is tracked in epics and issues. We follow the [The Infrastructure Platforms Project Management processes](/handbook/engineering/infrastructure-platforms/project-management/)

### Starting a new project

Every project starts with an epic. Follow the [Infrastructure Platforms epic guide](/handbook/engineering/infrastructure/platforms/project-management/#epics) to create a new epic with the required information. The epic description should give the context, project scope, and intended outcomes. Often the epic will be an iteration of a larger project.
Every project starts with an epic. Follow the [Infrastructure Platforms epic guide](/handbook/engineering/infrastructure-platforms/project-management/#epics) to create a new epic with the required information. The epic description should give the context, project scope, and intended outcomes. Often the epic will be an iteration of a larger project.

- Every project should have a DRI assigned. The DRI is responsible for making decisions, maintaining the epic and issues, and providing the weekly epic status update.
- We aim to have more than one person working on each project to allow for knowledge sharing. On projects with a single thread of work, we can knowledge share by working across timezones. Talk to your EM about the best way for the team to collaborate on work.
@@ -80,7 +80,7 @@ Follow the steps on https://gitlab.com/gitlab-com/gl-infra/epic-issue-summaries#

### Completing a project

After the planned work is completed, follow the [Infrastructure Platforms guide to finishing a project](/handbook/engineering/infrastructure/platforms/project-management/#when-a-project-is-finished)
After the planned work is completed, follow the [Infrastructure Platforms guide to finishing a project](/handbook/engineering/infrastructure-platforms/project-management/#when-a-project-is-finished)

## DevEx Grand Reviews

@@ -88,7 +88,7 @@ Every Thursday, the DevEx Senior EM, and one of the DevEx EMs, or their delegate

Before Thursday 17:00UTC, DevEx EMs use the epic status updates to [draft updates for the Friday Platforms Grand Review - internal link](https://docs.google.com/document/d/1gnoXNSpMXPfDqOyKRfIUHfNHUmSu88x8vjIeDOv73dE/edit?usp=sharing). The DevEx updates are finalized on [the internal issue before the Friday Grand Review](https://gitlab.com/groups/gitlab-com/-/epics/2115) recording.

See the [Platforms Grand Review handbook section](/handbook/engineering/infrastructure/platforms/project-management/#projects-are-reviewed-weekly-in-the-grand-review) for more details about the department approach
See the [Platforms Grand Review handbook section](/handbook/engineering/infrastructure-platforms/project-management/#projects-are-reviewed-weekly-in-the-grand-review) for more details about the department approach

## Developer Experience Demos

Loading