January 2015 Summaries

In the context of improving software testing efficiency, the text outlines the benefits of leveraging GitLab CI for running unit tests. By adding multiple workers to execute tests in parallel, users can achieve test completion three times faster than running them locally, which is typically expensive but made affordable with GitLab CI. The text compares costs among different CI services, highlighting that using GitLab CI with self-hosted runners significantly reduces expenses compared to Travis and CircleCI. GitLab offers free CI hosting for private projects, with the requirement to provide one's own test runners. Additionally, collaborations with Google Compute Engine and Digital Ocean provide users with promotional credits to facilitate hosting runners, although these offers are limited in time and availability. The implementation process involves setting up projects on GitLab.com, configuring build scripts, and potentially claiming credits to offset hosting costs, emphasizing the platform's cost-effectiveness and scalability for continuous integration needs.

The Ghost vulnerability in the glibc library, which is present on many Linux systems, has the potential to lead to remote code execution, although there is currently no evidence that it affects GitLab. Nevertheless, it is advisable to update system packages promptly. GitLab B.V. addressed this by running updates on all Linux machines and performing server reboots to ensure that all services using the C standard library were refreshed. To minimize downtime during these reboots, GitLab utilized a DRBD-based clustered setup for their production servers, allowing them to perform a fast failover from the active server to a stand-by server, thus maintaining service continuity.

The text humorously describes various archetypes of contributors to open-source projects based on their behaviors with Git, a version control system. It identifies seven types of contributors: the Build Breaker, who unintentionally breaks the build with small changes; the Repeater, who uses repetitive commit messages; the Wipper, who keeps merge requests open indefinitely; the Premature Committer, who commits excessively small changes; the Rebaser, who makes large single commits that can complicate debugging; the Merger, who frequently merges the main branch into feature branches to keep up-to-date; and the Denier, who refuses to accept responsibility for issues in their commits. Each archetype is accompanied by advice on how to improve their practices to better support collaborative software development.

GitLab's commitment to transparency and process improvement is evident in their handling of two notable service failures. In one instance, GitLab.com, their free SaaS service, experienced a significant eight-hour downtime, which impacted numerous users. GitLab responded by openly admitting their lack of immediate solutions, engaging the community for feedback, and implementing process improvements to prevent future occurrences, garnering positive feedback and trust from users. In another case, a missed consultancy call for a client led to an apology from GitLab's CEO and a detailed explanation of the corrective measures taken, ultimately resulting in the client upgrading their subscription. These incidents illustrate GitLab's approach of openly acknowledging mistakes, taking swift corrective action, and continuously refining their processes to enhance customer trust and satisfaction.

GitLab Enterprise Edition is positioned as a preferable alternative to GitHub Enterprise Edition due to its focus on enterprise needs, ease of operation and scalability, and inclusive nature. Designed from its inception as a tool for larger organizations, GitLab offers features such as branch protection, LDAP synchronization, and internally visible projects to facilitate collaboration across organizational boundaries. Its architecture is robust yet simple, allowing for easy scaling and customization, including running multiple servers to enhance performance and availability. As an open-source project with over 700 contributors, GitLab benefits from continuous improvements and maintains low costs, enabling widespread accessibility within organizations. This inclusivity contrasts with GitHub Enterprise's pricing model, which can limit access to developers, thus making GitLab an attractive option for organizations seeking comprehensive collaboration tools across various functional groups.

GitLab's upcoming 7.7 release on January 22nd will introduce significant user interface changes aimed at resolving issues in the current design, such as limited project navigation space, inefficient use of screen real estate, and overly complex navigation levels. The redesign process began by identifying these key problems, and a prototype was developed using a browser's web inspector to iteratively test changes. Community feedback was actively sought through social media, and a staging server was set up to allow users to experience the new design before its official release. This collaborative approach led to improvements that include relocating project navigation to the side to free up vertical space, simplifying navigation by eliminating a third level, and enhancing icon usage with a responsive design. The community's contributions were crucial in refining the final layout, which is now live on GitLab.com for early access.

GitLab has introduced the GitLab Community Forum, a central platform for users to discuss and share information about GitLab, as the community continues to expand rapidly. Hosted by GitLab B.V. and built on the open-source Discourse platform, the forum is run by community members and serves as a space for interaction rather than professional support from GitLab developers. Users can sign up with new accounts or use Mozilla Persona, with plans to support more OAuth providers in the future. Discourse's features allow for dynamic interaction, such as using topics as wikis, and a robust search function helps users find solutions efficiently. The forum includes various categories for organization, such as HowTo for sharing tutorials, Use Cases for enterprise deployment stories, and Configuration Management for setup enthusiasts, while also hosting sections for development, fan art, and discussions about ARM devices.

The series of blog articles chronicles the author's unexpected journey of writing a book about GitLab for PacktPub.com's Cookbook series, detailing the initial surprise of being approached by editor Vinay, the encouragement from his girlfriend, and the process with the publisher. Initially hesitant due to his background as a developer rather than a writer, the author overcame his doubts and began outlining chapters that included topics like installation, managing users, and GitLab CI. The blog post describes the challenges of estimating the book's length and the support received from the publisher throughout the process, including the use of a service called Signable for contract signing. The author intends to share further insights into the writing process in subsequent articles, encouraging readers to purchase the book for a deeper understanding of GitLab's functionalities.

GitLab.com initially hosted its growing number of public and private repositories on Amazon's largest instance, but due to escalating costs and limitations in vertical scaling options, they transitioned to using their own servers, specifically reconditioned HP DL180 G6 models. These servers, equipped with 24 CPU cores and extensive storage capabilities, allowed GitLab.com to manage the demands of nearly 20,000 active users and over 100,000 repositories while offering a cost-effective solution for the bootstrapped company. The move away from AWS required implementing DRBD for failover capabilities between a primary and a backup server, ensuring continuity in case of server failure. Despite the current infrastructure's efficiency, future plans include returning to Amazon AWS to facilitate horizontal scaling and leverage the recently announced larger EBS volumes for easier data migration.