GitLab Heroes Unmasked: How I am elevating my company using GitLab
A key to GitLab’s success is our vast community of advocates. Here at GitLab, we call these active contributors “GitLab Heroes”. Each hero contributes to GitLab in numerous ways, including elevating releases, sharing best practices, speaking at events, and more. The “GitLab Heroes Unmasked” series is dedicated to sharing their stories. Lee Tickett, director at IT development and support consultancy Tickett Enterprises Limited, is a GitLab hero and Core team member who continuously contributes to GitLab and provides exceptional feedback. In late 2020, he wrote a blog about how he came upon GitLab and began to use it as his company’s platform. At that point, his company was using GitLab in the following ways: for version control with a custom merge request approval process as a custom UI for streamlined/standardized project creation as an integration with our bespoke helpdesk platform as a Windows runner with fairly basic CI This blog picks up where that blog left off and gives insight into how Tickett Enterprises is making the most of GitLab’s One DevOps Platform for its helpdesk, CRM integration, CI/CD, and more. Migrating the helpdesk Quite some time ago, I decided to migrate from the bespoke helpdesk platform and use GitLab for issue tracking. Here’s an epic I created just over two years ago to start discussing my plans. I built a bespoke migration tool using C#, which connects directly to the existing helpdesk database and pushes the data into GitLab using the API. This includes: groups (each company in our helpdesk will become a group in GitLab with a single Helpdesk project) issues (every ticket in our helpdesk will become an issue in GitLab, estimates will be included and quotes converted to weights) notes attachments time logs labels (type, class, department, and “status” will be migrated to labels) Helpdesk workflow After discussing different approaches with the GitLab team and the community, we came up with the first iteration of our workflow process. The status of tickets in our helpdesk system becomes scoped labels in GitLab. It looks similar to the following: We have two relatively small teams so we can also leverage boards to distribute and manage work within the team: We will be leveraging the GitLab Triage RubyGem and Triage Ops project to handle reactive and scheduled automation, such as: opening pending issues once they reach their due date (this field has been slightly repurposed) nudging users when issues have been pended, but no due date has been assigned nudging the team when issues have not been triaged (labeled, estimates/quotes attached, etc.) GitLab triage will run as a scheduled pipeline from inside of GitLab, and Triage Ops (formerly known as Triage Serverless) will run as webhooks in AWS Lambda (triggered by webhooks). We may potentially transition some of our existing customizations from C# to GitLab Triage/Triage Ops, too. Building out CRM One of the biggest challenges moving our helpdesk over to GitLab was the inability to tie issues to Customers. So, roughly a year ago, I decided to start building out a Customer Relations Management (CRM) feature. You can see some of the work that has gone into the CRM so far: CRM Merged MRs. It’s surprising how much work is needed for what seems like a mostly simple feature. Despite careful planning, there were many surprises that caused […]
