I have been using GitLab for about 3 years, starting with this 5.0 release blogpost I ended on while digging for an on-premise open-source alternative to GitHub, after ages as a Trac user. Looking back now, it’s amazing how it grew up to what it is today, and choosing GitLab was one of these key decisions one take in life. On many sites, developers fall in love with that tool for every day tasks, managers feel secured with the great insight they got on both code and operations, CTO being okay with that because no lines of code are leaving the company.

Choosing #GitLab was one of these key decisions one take in life... Tweet this

Fully satisfied with their GitLab on-premise instance, teams begin habits of efficient, distributed and collaborative work: chunking and assigning issues between each one skills, managing deadlines and projects through milestones, improving communication at all stages. In a matter of weeks, it always become clear GitLab is and will be central to developers teams. This is ideal timing for part 2.

Each company, site and team has its own set of processes and rules, its own culture. When GitLab is integrated in company culture, it’s time to seize opportunities to speed-up and improve every little detail of the overall workflow. Sometimes it simply ends up with creating global labels or documentation pages to ease integrating a new teammate. Sometimes it leads company to try Enterprise Edition features. But most of the time comes the need for automated helpers or pseudo robots, which are backed by webhooks and API.

Many use cases led me to build GitLab robots, here are some of the most interesting ones:

• long before Merge Request Approval came to GitLab EE, I was asked for an efficient and clear review process, where named team members (gatekeepers, technical leads or team leaders) are allowed to approve a merge request by simply commenting they reviewed it, whithout anyone being able to accept that merge request before the explicit code review,
• to enforce branching and forking strategies over projects, protected branches are not safe enough as a human mistake is always possible (see code 18 for a quick nerd joke), so I built a robot listening to webhooks to ensure target_branch and target.path_with_namespace matches the appropriate source counterparts configured by the team, automatically commenting and closing unlawful merge requests,
• integrated code quality gatekeepers to these robots at the merge request level, like SonarQube with the awesome sonar-gitlab-plugin, disabling users from accepting merge request without a very special and conscious comment to bypass the quality rules configured…

Over the years, I realised that #GitLab is talking with all the team consciousness Tweet this

Building with and for it, over the years, I realised that GitLab is talking with all the team consciousness, computing all the data committed, merged and commented inside, it’s web interface being only one way of communicating with it. Twist of fate, at the exact same moment I was thinking about this, I was called for the need of a Gantt chart over GitLab issues. Time to energize: that was a job designed for me! We saw gitlab-org/gitlab-ee#985 and former issues, left aware that with current release cycle we would have to wait for about 5 or 6 months. But my client’s managers were desperate about this one, which was on their top 3 missing tools for too long, and needed a quick and efficient answer, something disruptive.

Quick and efficient… I never used a Gantt chart before. Last time I saw one was on a complicated software screenshot: it left me thoughtful and respectful about the level of professionalism achieved by people using these type of charts.

Don’t be impressed and think simple. Starting from scratch, each GitLab issue would be a line on the chart, the Gantt start for an issue could be its creation time, and the Gantt end the issue due date. Actually, the base work was that simple! The only data missing was a configurable start date, as for sure an issue could be created long before it’s scheduled. To keep things simple, I decided this should be added right in the issue description to avoid storing any data outside GitLab and the issue itself, GanttStart: string was born.

That’s how, leveraging my Bootstrapping Vue.js with vue-cli article, I started with this sentence in mind: “An ideal case to build a Single Page Application, is using APIs to bring data in […] your job is limited to putting things together and make it work the way you need.”. And this is how it all started:

docker run -it -p 8080:8080 --rm -w /GanttLab -v $(pwd):/GanttLab node:6 /bin/bash
npm install --global vue-cli
vue init webpack . # by far the most awesome part, but Docker stuff was too
npm install
npm run dev

Funny fact, the docker run command is in the bashInDevEnv script.

Keeping things simple, and building boring solutions will definitely help you ship software that works, fast. The key here was to choose not to store any data, keeping it all tied to the issues, and focusing on how GitLab API used from a frontend only application could get the job done in about 2 days and 9 commits. There is always time after shipping your initial working version to improve it and make it better, day after day. Community helps a lot on public projects. Part of this refinement for me was building vue-gitlab-api (a deadly simple Vue.js plugin to consume GitLab API) which was integrated as a GanttLab dependency to lower its code base, and iterating over simplicity to avoid installing for preview or daily use by publishing it live (and for free) on GitLab Pages.

Here, this story could be labelled “to be continued”, and it is actually: follow up what’s getting done on the GanttLab repository activity feed, and comment on its issues to get involved and be part of it! I can’t wait to see where we will end up!