Quên Github đi, hãy dùng Gerrit

Không biết có bao nhiêu bạn nghe nói đến Gerrit rồi nhỉ. Thật sự là bản thân mình cũng không biết đến khi công ty triển khai áp dụng. Gerrit là một web tool dành cho Code Review dùng với Git. Bạn có thể hình dung Gerrit giống như Gitlab, dựng được standalone server và dùng thay thế cho Github.

Gerrit là công cụ code review cho team Android của Google. Đây là public Gerrit cho Android source: https://android-review.googlesource.com/#/q/status:open

Vậy tại sao lại Gerrit ?

Gerrit vs Github

Mình không có kinh nghiệm về Gitlab nhiều nhưng về cơ bản thì Gitlab khá giống với Github Enterprise, dành cho các công ty muốn tự triển khai trên cơ sở hạ tầng mà không muốn mua gói của Github.

Tuy nhiên Gerrit lại là một công cụ hoàn toàn khác và định nghĩa nên một workflow khác với khi bạn làm việc trên Gitlab/Github.

Gerrit thích hợp cho những core-linux dev, những người vốn bản chất chỉ thích git chứ không phải github, vốn chỉ cần công cụ quản lý mã nguồn chứ không dây dưa với các yếu tố social  Hơn nữa, Gerrit có 2 điểm mạnh hơn hẳn

• Gerrit bắt buộc mỗi commit đều phải là một commit đẹp, từ đó tạo nên một history đẹp cho dự án
• Gerrit có cơ chế review -2, -1, 0, +1, +2 hiệu quả và rõ ràng hơn Github.

Tuy vậy Gerrit cũng có nhược điểm, UI và UX không được đẹp, nhìn rối mắt so với giao diện shiny của Github. Tuy vậy sau một thời gian dùng quen thì hiện tại mình (và team mình) cảm thấy không thể sống thiếu Gerrit !

Mỗi commit phải là một commit đẹp

Khi team dev với Github, bạn ném một PR(Pull Request) lên và đợi review. Các Reviewer bắt đầu gạch đá tung tóe. Bạn vội vàng “fix comment” trong một vài commit tiếp theo. Sau cùng bạn ấn nút Merge, và ala, history của dự án giờ sẽ thế này

Không nói là bạn không thể sửa chữa được tình huống này, tuy nhiên flow làm việc dựa trên PR-based của Github đã để cho những tình huống này dễ xảy ra.

Gerrit, ngược lại, mỗi review là commit-based, tức là review đem lên là review chỉ có 1 commit duy nhất. Sau khi lãnh gạch đá thì việc phải làm là sửa và commit –amend. Lịch sử giữa các lần sửa được xếp thành các patch và có thể xem cụ thể trong review, nhưng khi merge vào master thì chỉ là 1 commit duy nhất.

Cơ chế này bắt buộc mọi thành viên phải cẩn thận với từng commit, và giữ cho git history luôn luôn sạch sẽ.

Đây là một review sample: https://android-review.googlesource.com/#/c/215032/

Cơ chế Review

Một Review đưa lên Gerrit sẽ có thể được comment theo 5 mức điểm: -2, -1, 0, +1, +2. Với mỗi reviewer thì cách thể hiện như sau

• -2: Không thể chấp nhận được, tao sẽ không để commit này vào history
• -1: Không tốt tí nào, nhưng tao không chắc chắn lắm, thằng nào khác xem lại nhé
• 0: Ok | No idea
• +1: LGTM, nhưng cần người khác xem thêm
• +2: Quá chuận rồi, merge thôi còn gì nữa!

Một review sẽ được merge khi có ít nhất một +2. Ngoài ra nếu đang có -1 hoặc -2 thì sẽ không thể ấn nút merge. Team mình hay đặt 1 con jenkins verify code/ chạy test, nếu fail thì tự động -1, success thì tự động +1.

Kinh nghiệm thực tế cho thấy cơ chế này giảm mis-communication và tăng hiệu quả code review rất nhiều.

Gerrit còn một số ưu điểm nữa như comment trong code rất dễ dàng, code compare hiển thị sẵn theo 2 cột, hiện những review nào đang liên quan đến review hiện tại hay phím tắt trên màn hình cho vimmer! Với true geek thì có lẽ so với Gerrit, Github chỉ là đồ … vứt đi

Techtalk via kipalog