The prime directive of the Business Technology Engineering group is to achieve maximum iteration velocity with designing, developing, and implementing automation efficiencies using software and systems to improve GitLab's business processes, software systems, and cloud infrastructure. Our collective group is broken into smaller functional teams that focus on one or more specialized areas.
The Business Technology Engineering team focuses on three primary competencies:
|Name||Role||Focus Areas (Specialties)|
|Daniel Parker||Senior Integrations Engineer||Enterprise Applications and Integrations|
|Karuna Singh||Integrations Engineer||Enterprise Applications and Integrations|
|Dominic Roy-Stang||Integrations Engineer||Enterprise Applications and Integrations|
|Jeff Martin||Senior IT Systems Engineer||Access Manager, Infrastructure, Demo Systems, Training Labs|
|Dillon Wheeler||IT Systems Engineer||Access Manager, Infrastructure, Operations|
|Marcus Whitaker||Senior IT Systems Engineer||Okta Integrations, Operations|
|Mohammed Al Kobaisy||IT Systems Administrator||Okta Integrations, Operations|
|Name||Role||Business Engagement Focus Areas|
|Bryan Wise||VP, Business Technology||VP+ level requests, new programs, infrastructure managed services|
|Christopher Nelson||Senior Director, Enterprise Applications||Enterprise Applications and Integrations Engineering|
|To Be Hired||Senior Director, IT Operations||TBD|
|Peter Kaldis||IT Manager||Access Manager, IT Operations|
You can see each of the functional teams below with links to the respective handbook pages.
Each functional team has the autonomy to make their own decisions of how they work in alignment with the company values of collaboration, results, efficiency, and iteration. This was decided collectively during the Business Technology Engineering Symposium call where we evaluated how each of us work, what works best for us, the balance of planned milestone sprints vs reactive kanban requests, and the unique dynamics of each functional team's scope of responsibility and day-to-day needs.
If we are already doing related work, feel free to ask in our respective Slack channel or create an issue in the respective issue tracker.
For new programs or larger requests, please reach out to a member of the leadership team to start a "Business Engagement" discussion.
If in doubt of how to engage or wish to informally ask, simply send a message to the DRI on Slack or create an issue on the respective issue tracker or in our catch-all Engineering Operations issue tracker.
The Access Manager Engineering team focuses on Identity and Access Management (IAM) and Role-Based Access Control (RBAC) automation for all of GitLab's tech stack applications.
In FY21-Q4, we launched the GitLab Sandbox Cloud, powered by HackyStack to automate the provisioning of AWS acccounts, AWS IAM users, GCP projects, and GCP users. This has allowed us to automate a large portion of our AWS and GCP access requests.
In FY22-Q3, we launched the initial technical discovery and custom development prototype of GitLab Access Manager (codename "Project FastPass") that will eventually replace access request issues and manual provisioning with a streamlined custom web UI and API integration with all of our tech stack applications for user and role provisioning. It is expected that the first phase of GitLab Access Manager will launch in late FY22, and we are considering releasing Access Manager as an open source tool in the future.
You can track the real-time progress in the Project FastPass Issue Tracker.
The GitLab Access Manager documentation draft is available at https://docs.access.gitlabenvironment.cloud for internal education and security compliance review.
The application is in the early stages of design and development and does not have a live preview of functioning version yet.
Access Manager is a custom full stack application built by the GitLab Business Technology team ("IT") that provides a user interface ("UI") for team members, managers, access approvers, audit reviewers, and IT administrators to centrally approve and manage role-based access to the directory of tech stack applications ("SaaS providers").
Access Manager has back-end automation that uses the API for each SaaS provider to automate user account and role provisioning (after approval) and has scheduled deprovisioning of user accounts based on expiration or offboarding date.
There are several additional features for streamlining access/audit reviews and compliance reporting using the UI, API, or CSV exports.
In other words, the functionality of the application focuses on the automation and auditability of the lifecycle of Identity and Access Management ("IAM") and Role Based Access Control ("RBAC") for team members and our tech stack applications.
It is important to distinguish that Access Manager automates the provisioning process for SaaS Provider systems behind the scenes, and users still use Okta as our single sign-on identity provider. For SaaS Providers that do not support Okta authentication, Access Manager uses the API to provision a local authentication username and password that is automatically deprovisioned when the team member access expires or is offboarded.
The Enterprise Applications Integrations team designs, builds, and maintains the complex ecosystem of automations that exist in our Enterprise Applications ecosystem using a hybrid of custom developed code in our Platypus codebase (powered by Nest.js) and/or Workato integrations platform-as-a-service (IPaas).
In FY21-Q3, we launched v1.0 of Platypus. This release includes all of the work we’ve done so far to stand up Platypus and get it ready for projects. Going forward release versions will be bumped at the end of our monthly milestones and include the changelog of the work done in that milestone. We are releasing code to production on a daily basis, these versions just serves as a marker to capture a snapshot of the work we’ve done in each milestone.
You can learn more about Platypus and our capabilities and offerings on our handbook page or ask in the
#bt-integrations Slack channel.
The Business Technology Infrastructure Engineering team ("BT Infrastructure") focuses on the architecture, access management, cost labels and tags, naming conventions, and organizational hierarchy for AWS and GCP infrastructure across the organization, except for the GitLab SaaS realm (where GitLab.com is hosted) that is managed by the Engineering Infrastructure department.
We collaborate closely with the Infrastructure Security ("InfraSec") team that is responsible for best practices and implementing security policies to mitigate risk.
We also provide escalation engineering and triage support for the Security Incident Response Team ("SIRT") and Security RED Team when security anomalies, events, or incidents require AWS/GCP subject matter expertise.
In FY20-Q4, we launched the Demo Systems for the Customer Success department to have a shared sandbox environment for demonstration and training class purposes. You can learn more on the demo systems handbook page.
In FY21-Q4, we launched the GitLab Sandbox Cloud, a deployment of our open source HackyStack project (powered by Laravel) to automate the provisioning of AWS acccounts, AWS IAM users, GCP projects, and GCP users. This has allowed us to automate a large portion of our AWS and GCP access requests.
We are in the process of adopting the Infrastructure Standards Labels and Tags to get better visibility into cost allocation for all of the AWS and GCP resources that are provisioned across the organization.
If you want to deploy new infrastructure in AWS or GCP, the process depends on the purpose. You can get links to self-service instructions and issue templates in the BT Infrastructure Issue Tracker README.
For additional guidance or questions, please ask in
#infra-access-requests or send a Slack DM to Jeff Martin.
The Operations Engineering team is responsible for providing escalation engineering support for the IT Operations team (Help Desk Analysts, Systems Administrators, IT Compliance), particularly with writing automation scripts and customization and iteration implementation requests for tech stack applications (notably Okta, Google G-Suite/Workplace, etc).
This team is intended to serve as a catch-all for all day-to-day requests to avoid disrupting the planned milestones for larger projects that the other teams are working on.