Going your own way with GitLab
Share on socials
Going your own way with GitLab
Val Naipaul
January 23, 2024
9 min read
Val Naipaul
January 23, 2024
9 min read
Jump to Section
Jump to section
Common approaches
Proposed approach
What about Auto DevOps?
If you work on the platform side and/or DevOps, and find yourself facing a migration or implementation of GitLab (SaaS or self-managed), it may be dawning on you that GitLab has a lot of knobs and switches.
It is indeed a comprehensive platform that covers the breadth and depth of your needs, with its core VCS, CI/CD pipelines, package management, software composition analysis, planning capabilities, and more.
But do you need to implement all of its features in order to be successful? Especially with GitLab Runners deployed on cloud impacting your bottom line.
In this blog, we propose an approach to planning a GitLab migration or implementation that delivers value to stakeholders sooner and helps teams to engage with GitLab on their terms, without necessarily going full throttle.
Common approaches
Before we get into our proposed approach for a GitLab migration or implementation, let’s touch on some common approaches for context, one of which may even be more well-suited to your situation.
Big bang (migration)
The big bang approach involves iterations of analysis, configuration, ETL, and validation, possibly using representative source content at first, progressing to the full source content, culminating in a final ‘big bang’ migration.
The main benefit is a clear cutover point for all involved, but value is deferred until that cutover point. The iterative nature of this approach can create structural inefficiencies as well, in the form of overheads around the migration iterations.
Incremental, Phased (migration)
In an incremental approach, the source content is partitioned and migrated in increments. This can still be done in an iterative fashion, as with the big bang approach, but with more manageable iterations.
In a phased approach, capabilities of the target environment are activated in phases, with each phase building upon those prior.
With both of these approaches, value is realised sooner than with the big bang method, but both source and target platforms are live for an extended period, from the first increment or phase to the last, which can become burdensome and confusing.
Platform engineering with self-service (migration/implementation)
With the platform engineering with self-service approach, a team of experts lays the groundwork (configuration, automation, guardrails) to enable development teams to help themselves with GitLab, whether that involves migrating content, onboarding, or bootstrapping new projects using permitted and endorsed templates.
Proposed approach
A value-prioritised, shift-left approach to GitLab migration or implementation
The approach we propose prioritises value delivery to stakeholders while pacing the implementation to ensure solid engagement between users and GitLab.
For example, if your teams are eager to use GitLab Review Apps for collaboration (and to reduce their infrastructure bottom-line, maybe), you might consider external repository integrations as a bypass to Review Apps before Git repositories have been completely migrated or even before migration has begun!
While accelerating the rollout might make sense in some aspects, it may be beneficial to slow roll others, like automatically mirroring issues from an incumbent planning tool into GitLab Team Planning. This will allow developers to switch over at their own pace, with minimal disruption.
Incidentally, while not normally used in the context of platform implementation/migration, ‘shift-left' thinking is really at the core of this approach. You'll be broadening the plan to address the various stakeholders and their concerns (e.g. cost, developer experience) alongside normal platform implementation/migration concerns.
General principles
This approach entails first identifying your criteria for success with GitLab, then prioritising each in terms of three attributes:
- Importance/urgency or "size"
- Implementation cost
- Traction (the human capital, expertise, and commitment needed)
Proceeding with the migration or implementation according to the determined priorities will deliver value sooner to stakeholders while fostering teams' engagement with GitLab.
Identify your criteria for success.
By what criteria will success be measured (by all stakeholders, not just by your team)? Identify at least two criteria but no more than five.
Your criteria, such as the well-known DORA metrics, may be associated with DevOps. But remember, this is about your environment: do security and compliance concerns dominate? Is there significant interest in rigour and transparency around testing?
Prioritise your criteria for success and pair with GitLab features
For each success criteria:
- Assign a number to represent the relative size, using 1 for the least (more important/urgent criteria are higher priority). Leave gaps across criteria to represent better relative values, e.g. 1, 2, 3, 5, 10.
- Assign a number to represent the relative implementation cost (including tools and processes) to move from the current to the target state (with respect to the criterion), using 1 for the most (criteria with lower implementation costs are higher priority). For the target state, think short- to medium-term, but remember to be a bit ambitious – getting there should feel like an achievement.
- Assign a number to represent the relative traction, using 1 for the least (criteria with the highest traction deserve higher priority). Ask whether you have the human capital, expertise, and commitment to realise gains.
- Now rank the criterion against the others by the product of its size, cost, and traction, resulting in higher priorities being numbered higher.
- Identify relevant GitLab features that could help (or hinder) and explain how. Be inclusive to begin with and refine as necessary, possibly in consultation with stakeholders.
Copied!
For example:
Success Criteria - Collaboration
- Size - 5
- Cost - 4
- Traction - 4
- Value - 80
Relevant GitLab features
- InnerSourcing with a minimal group hierarchy
- Move sensitive content out of repositories and activate Secret Detection to support InnerSourcing (and improve security)
- Pipeline composition techniques, such as pipeline reuse through templates, CI/CD components and CI/CD catalogue
Success Criteria - Operating costs
- Size - 1
- Cost - 3
- Traction - 3
- Value - 9
Relevant GitLab features
- Review Apps for ephemeral test environments
Success Criteria - Operating costs
- Size - 3
- Cost - 1
- Traction - 1
- Value - 3
Relevant GitLab features
What about Auto DevOps?
But what about Auto DevOps? Doesn't it accommodate diverse branching models, development methodologies, and history – non-uniform content, in other words? Could we not just skip this prioritisation and deliver everything simultaneously with Auto DevOps (setting aside cloud operating costs)?
No, and no; Auto DevOps (which is just a set of curated pipeline jobs) succeeds as a good model and starting point for DevSecOps, one that lends itself to customisation and/or inspiration for your own reusable CI/CD components and CI/CD catalogue, but it is not a 'model-of’, just a 'model-for’.
In closing
Hopefully, this blog post makes you feel better equipped to proceed with a GitLab migration or implementation, whether SaaS or self-managed, with a broader perspective on planning for a successful outcome in your environment.
With the approach we have proposed – prioritising your criteria for success according to their respective size, implementation cost, and traction – your stakeholders will see value from GitLab sooner. Your users will enjoy meaningful engagement with GitLab as they see their concerns being addressed in the implementation.
As we mentioned up top, GitLab has a lot of knobs and switches. For best results with our proposed approach to GitLab migration or implementation, investigate all the features on offer (paying attention to the applicable subscription plan, Premium or Ultimate). That way, you'll know which features best support your success criteria.
Get in touch to learn more!
Written by
Val Naipaul
Principal DevOps Consultant
Val applies DevOps thinking to real-world problems, developing our DevOps practice, and sharing ideas and experiences with clients and partners. Val enjoys working with diverse stories and perspectives to drive innovation.
DevOps
GitLab