Professional Services EM Implementation Scoping
:warning: This page is under construction
Implementation Scoping Details
-
We have scoped several different reference architectures in the past. Examples can be found in the Deployment Equations tab of the Engagement Estimates TEMPLATES document.
-
Implementations will use the standard documented reference architectures.
-
All implementation services on prem with Geo included assume that we use a single large omnibus implementation for the secondary. There are some challenges with full HA secondaries, so if we choose to scope an HA Geo, the general rule of thumb is to add an additional 20-25 days to the scope to account for the complexities.
-
Implementations on AWS tend to be less complex than on-prem implementations because we take advantage of the various services AWS provides for HA.
-
K8s implementations are generally the same effort as VM implementations, for the same sized reference architecture.
-
GitLab System Administration Basic and GitLab Advanced System Administration training classes are typically included in the project scope for implementations. These courses provide foundational concepts for configuring, administering, and troubleshooting GitLab for both single node Omnibus and HA implementations. At this time, we do not recommend these classes for any Kubernetes implementation as the course content does not reflect the kube-specific commands that users need to run for Kubernetes implementations. Customers will get “trained” on backup/restore and upgrade activities during the standard implementation activities. Additional consulting days/post-deployment Q&A sessions can be added to scope to help the customer ramp on any administration topics.
-
Our PSE team uses infrastructure as code automation for provisioning infrastructure and configuring the provisioned servers. The tooling is managed in the Proliferate project. The project readme has information on what infra as code we currently support. Note, this is different than the open sourced GitLab Environment Toolkit used by our QA team for provisioning new systems using Terraform and Ansible.
Using the services calculator, an SA/SAE/AE/CSM can create a scoping issue, and work with an Engagement Manager to iterate and refine the services estimate for a customer. In this issue, we have included additional context to the Implementation Scoping Questions, which can be previewed below
| Scoping Question | Customer Response | Example response | Rationale for asking |
|---|---|---|---|
| License level (support for HA requires at least Premium) | to-do | Premium | Validates that the Customer will have the appropriate license needed in order to install, configure and use the requested features. |
| Is this a brand new install of GitLab or do they have an existing instance that they are trying to scale up? | to-do | New Install | If the customer is an existing GitLab deployment and what to move to a new system with stronger availability/stability requirements, we will want to talk about upgrading the current deployment vs standing up a new one then migrating their data. |
| How many users does the customer expect to have on GitLab when fully implemented? | to-do | 3,250 | The number of users helps us ensure we’re implementing an infrastructure that will support the number of users they have, based on GitLab Reference Architectures. |
| Does the customer have a hard requirement for high availability (HA)? | to-do | Yes - 99.5% availability is our goal | Availability requirements help us understand what architecture we will be deploying, which helps us scope the engagement accurately. |
| Does the customer need secondary site mirroring (Geo) to improve performance for geographically distributed teams or for use for disastor recovery (DR)? | to-do | Yes - Primary will be in AWS US-east, GEO Secondary in US-west | We need this information to accurately account for time to build and configure a Geo secondary configuration in the estimate. |
| Will the GitLab IaC using terraform and ansible, or CloudFormation on AWS, be acceptable or are there customer-specific IaC requirements? | to-do | Terraform + Ansible preferred | GitLab provides standard Infrastructure as Code (IAC) via terraform and ansible for most deployments. We can offer CloudFormation for AWS, and Helm chart for k8s implementation. If a customer wants different IAC, e.g. Puppet or Chef, then we will need to consider whether we have written this before for a customer or if additional effort needs to be factored in to account for this work. |
| Where is this going to be installed? (AWS, Azure, GCP, on-prem in client’s data center) | to-do | AWS | Helps us validate the implementation architecture. AWS deployments are typically less effort than on-prem due to our experience with this cloud and the various services built-in for HA; other clouds (Azure, GCP) might require additional effort. |
| Does the customer plan to install on Kubernetes? If yes: - what k8s implementation will be used (EKS, GKE, AKS, Openshift)? | to-do | Yes, EKS | This changes the deployment architecture (stateless in K8S, stateful in cloud managed storage services) and affects how we scope the implementation engagement. |
| What is the customer’s experience level with Kubernetes administration? - Is the customer ok with deploying via Helm? | to-do | Beginners. We’re not familiar with Helm | We ask this to ensure customer platform teams have the appropriate required knowledge to deploy and maintain the system using Helm. We dont want customers unable to maintain their deployment after the PS engagement ends. |
| Is there a specific OS required by the customer? (e.g. RedHat Enterprise Linux (RHEL), CENTOS, Ubuntu etc.) | to-do | RHEL | Some deployment tools that we can use only support specific operating systems, which can affect the size of the implementation service engagement. |
| For non-cloud implementations, do you have Redis, nfs etc appliance? | to-do | Yes, we’re using NFS for git storage. | Deploying NFS is not recommended as it is in End of Life. Need to know if there are hard requirements for this to provide appropriate guidance in architecture design. |
| Does the customer require the GitLab instance to be it air-gapped, i.e. the instance will not be able to connect to the internet? | to-do | Yes, we won’t allow the GitLab system to connect directly (or through proxy) to the internet. | Without a way to get to the containers that GitLab CI needs to run build, test, scan, and deploy jobs, the value of GitLab is greatly reduced. If this is the case, we would scope in an effort to build a way to periodically pull in these containers, scan them for security vunlnerabilities, and host them internally on a container registry. |
| Does the customer require a proxy to get out to the internet from the GitLab deployment? | to-do | Yes | This is a common approach to reduce security attack vector. To ensure GitLab can function properly, we will help you configure the GitLab system to work with a proxy to ensure GitLab CI jobs can pull containers from registries hosted on the open internet. |
| Will the customer use a publicly trusted certificate or will they use a non-standard Certificate authority? Is the certificate readily available or does it still need to be issued? | to-do | Using publicly trusted certs. Yes we have provisioned the cert already | Publicly trusted certs enable the GitLab standard deployment to be seamless. If there is a non standard Certificate Authority, the deployments are more complex. And if the certs have not yet been acquired, the project could see delays. |
| GitLab, by default, terminates encryption at the load balancer and does not use encryption in transit between GitLab components. Is this encryption method sufficient or will encryption in transit between the components be required? | to-do | Require SSL between all components | If we need to enable SSL in between all components, the configuration takes longer and needs to be accounted for in the engagement estimate. |
| Does the customer require highly available git storage? | to-do | No, we can use a strong backup/restore policy to reduce maintainability burden | GitLab has a feature called gitaly cluster that replicates git data across many gitlay nodes to ensure the git data is highly available. This feature requires a minimum of 10 additional nodes to the deployment architecture and thus comes with additional maintenance burden. This tradeoff should be considered so we can scope the engagement accurately. |
| For non-cloud and non-kubernetes deployments, what is the hypervisor (e.g. VMWare) that the customer will use for managing VMs? | to-do | N/A - using AWS | This helps us understand if we have the skillset internally to deliver or if we need to work with a partner for fringe hypervisors. |
680a0bc8)
