In this case study


WWT's Application Services development teams were using native Git fronted by Apache on a Linux Virtual Machine (VM) as an internal tool for managing source code of software development projects. Management of project permissions in Apache was a challenging, multi-step process that required creating an Active Directory User Group and populating it with the correct users; creating a new project folder structure and configuring Apache to wrap user authentication around that folder; and finally initializing the folder itself as a Git repository. 

If a project needed a second Git repository, this process would have to be repeated. There was also no user interface for viewing or managing Git repositories. Furthermore, because of the technological limitations of Apache fronting native Git, teams were not empowered to create new repositories at will for their projects. While turnaround time to create a new repository was minimal, it had to be completed manually. The cost of completing these manual tasks could be offset with a fully featured version control system.

The team saw an opportunity to improve this process and create a better experience for the end users. 


WWT's Application Services IT Operations group wanted to provide a better experience to its software development teams—and their clients—while increasing the control of project code (client code). The group needed a solution that allowed developers to control the build process as part of what was in source control. 

After GitLab was trialed by a development team, it was proposed as a replacement to the current in-house solution of Apache plus native Git. The team wanted a program that would allow users to check that all into source and build change with our app. The IT Ops team created a GitLab instance that was hosted in a WWT data center. 


The new GitLab instance is accessible to internal and external users (clients) with granular permissions being granted through the UI. Giving clients the ability to see the codebase and build pipelines as WWT develops new applications has increased transparency, collaboration and trust with clients

Leveraging the omnibus installer has enabled a near 100 percent successful upgrade rate every month. GitLab has been one of the most stable solutions implemented while continually adding new features.

ACE automation (an internal project management tool) enabled teams to control who had access to GitLab and at what level (read/write or read only). If a person joined or left a project, the team was empowered to update the access rights without having to open a ticket with IT Operations. 

GitLab CI and its runners (systems that executed build pipelines) enabled the team to keep their build and deployment processes as a codified file that existed alongside the application codebase. This created a more holistic view of how to successfully create, build, test and ultimately deploy client applications. Additionally, it reduced the friction of portability as long as GitLab was being used wherever the code base was relocated. If not, the human-readable GitLab CI file could easily be re-written to be used in another build pipeline tool.

GitLab runners further extended the service offering by providing existing infrastructure for teams to run their builds against. Leveraging the concept of containerization, teams could specify a Docker container to which they would run their builds within and have an immutable system that would produce consistent results across multiple build iterations. This also reduced overhead of IT operations because they no longer had to process requests for virtual and physical build boxes. Eliminating the need to request additional resources from IT operations sped up the team's ability to provide value to clients.