Move /infrastructure product and platform pages to /infrastructure-platforms (f2f44b0d) · Commits · GitLab.com / Content Sites / handbook · GitLab
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

.gitlab/CODEOWNERS

−1

content/handbook/engineering/architecture/design-documents/cells/topology_service.md

+1 −1
Changes for content/handbook/engineering/architecture/design-documents/cells/topology_service.md: 1 added line, 1 removed line.
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?

content/handbook/engineering/architecture/design-documents/sast_ide_integration/decisions/001_provide_api-based_security_scans.md

+1 −1
Changes for content/handbook/engineering/architecture/design-documents/sast_ide_integration/decisions/001_provide_api-based_security_scans.md: 1 added line, 1 removed line.
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.

content/handbook/engineering/infrastructure-platforms/_index.md

+6 −6
Changes for content/handbook/engineering/infrastructure-platforms/_index.md: 6 added lines, 6 removed lines.
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/).

content/handbook/engineering/infrastructure-platforms/developer-experience/_index.md

+4 −4