August 2015 Summaries

Containerization's rise through platforms like Docker and rkt has streamlined application development but also posed challenges for maintaining up-to-date container images in continuous integration pipelines. Quay.io, developed by CoreOS, offers a solution by transforming source code from platforms like GitLab into Docker images with each code push, thereby enhancing efficiency and teamwork for developers. By seamlessly integrating with GitLab, Quay.io allows for automatic syncing and building of container images, simplifying the identification of issues and testing of updates. Setting up this integration involves a straightforward process of linking GitLab repositories with Quay.io, authorizing access, and configuring build triggers, ensuring that any push to a GitLab repository results in an immediate build on Quay.io. This integration empowers developers with reliable, updated Docker containers for rapid testing and deployment, with Quay.io offering a free trial and enterprise options for various deployment needs.

GitLab has announced the integration of GitLab Mattermost, an open-source, on-premises messaging app similar to Slack, into its Omnibus packages starting with GitLab 7.14. Designed to enhance internal communication for remote companies, GitLab Mattermost addresses the need for on-premises software due to security and control concerns, as Slack does not offer such a version. By collaborating with the Mattermost team, GitLab has facilitated the integration of PostgreSQL support and OAuth login to connect with GitLab's OAuth provider. This move ensures that Mattermost can be easily installed via the Omnibus package, though it remains in an alpha state with planned security audits and a beta release targeted for GitLab 8.0. The integration is expected to provide a seamless setup with minimal package size increase and includes future plans to improve interactivity between GitLab, GitLab CI, and GitLab Mattermost.

Since GitLab 8.2, both GitLab Community Edition (CE) and Enterprise Edition (EE) have supported Git Large File Storage (LFS), following a path towards production-level support that began with a reference implementation not initially ready for production use. GitLab was compelled to develop its solution because existing solutions for managing large files in Git repositories, such as Git Annex, were not sufficient, and GitHub's Git LFS was not initially production-ready. GitHub had announced Git LFS and open-sourced its client and server reference implementation in 2015, which sparked interest from the GitLab community for similar support. Despite not receiving direct responses from GitHub, GitLab decided to fork the Git LFS reference implementation, remove unnecessary user management features, and incorporate it into both CE and EE versions. GitLab's open-source efforts began with contributions from the community and anticipated further input, aiming to release an alpha version with GitLab 8.1 and a beta in 8.2.

Code review is crucial for preventing technical debt, though its timing is vital for maintaining project velocity. The Quora article on maintaining velocity suggests that post-production code review might be mistimed. Reviewing code before deployment offers several advantages, such as preserving the developer's context, reducing resistance to change, emphasizing code quality, and catching mistakes early, all of which contribute to more reliable software and fewer emergency bug fixes. Early code review can be enforced through workflows requiring approval from multiple reviewers, ensuring it is not skipped, and smaller, more frequent reviews tend to yield more detailed feedback. The discussion highlights the importance of refining code review processes and invites feedback for improvement, particularly in tools like GitLab.

GitLab is transitioning to a more open development process by moving its internal issue tracking and discussions to public repositories on GitLab.com, enabling greater community involvement in the development of both its open and proprietary software versions. This shift aims to address previous issues such as duplicated bug reports, lack of transparency, and limited community insight into planned features, thereby fostering better features and faster bug fixes through increased feedback and contributions. While sensitive issues like security concerns will still be handled internally, the change will allow customers to view progress on their issues and feature requests, enhancing collaboration between GitLab's community and its customers. Over time, GitLab plans to integrate feature requests into this public system, gradually phasing out their current feedback platform, while ensuring that customer interactions remain confidential through internal linking.