Tản mạn: chuyện Gitlab

1 Khi mình join team, công ty mình host các projects trên Github. Một dev mới vào công ty sẽ được add tài khoản Github cá nhân mình vào tài khoản organization của công ty. Lúc ấy, trên Github profile của bạn sẽ hiển thị membership với công ty (bạn phải public cái membership thì người khác mới thấy được nha). Nếu bạn làm cho công ty nào ok, hoặc thuộc dạng top-notch trong nước/khu vực, thì Github profile của bạn sẽ có-vẻ đẹp hơn một tí.

Ngoài ra, cái biểu đồ contribution trên Github cá nhân của bạn nhìn sẽ xanh xanh, đẹp hơn chút. Nhớ vào contribution settings chỉnh để tính luôn cả private contributions (tức là contribution vào các private repo) nha. Dưới đây là contribution của mình trong năm 2018:

Như bạn thấy đấy, thứ 7 cũng có màu xanh xanh nha, thấy làm việc cần mẫn chưa 😆!? Mình join công ty là cuối tháng 2, đến cuối tháng 8 là hết probation (ừm, probation có 6 tháng chớ mấy 😜). Xong tới cuối tháng 9 thì mấy ô xanh vơi hết. Hổng phải do pass probation rồi nên mình phè phỡn đâu mọi người. Lúc này là thời điểm migrate sang Gitlab xong. Team vẫn miệt mài push code và đi review code… nhưng trên Gitlab. Vì Gitlab công ty xài là self-hosted domain, cần VPN để truy cập, và mỗi người xài theo email account của công ty; nên ai cũng mong là “con ong làm mật yêu hoa”, chứ không kỳ vọng sẽ để lại dấu ấn trên public profile. Sau khi migrate sang Gitlab thì contributions của mình trong năm 2019 như thế này đây 😂:

2 Là một Github user, mới đầu chuyển sang dùng Gitlab mình thấy rất khó chịu vì cái UI/UX của nó. Cho đến thời điểm hiện tại, mình đã bớt khó chịu hơn. Tuy nhiên, cá nhân mình nghĩ là nó có thể làm tốt hơn. Lấy ví dụ về call to action (CTA) giữa Github và Gitlab:

• Đối với mình, thiết kế của Github có call to action rất rõ ràng. Ví dụ, khi bạn review 1 cái pull request (PR) của người khác, ngoài việc để lại comment trên code của người ta, hành động sau chót thường là approve PR hoặc request changes. Cái nút “Review changes” màu xanh lè nằm ở góc phải, vẫn cố định (sticky) ở đó khi scroll xuống, rất tiện lợi cho cả 2 chức năng trên vì có độ chú ý cao.
• Khi mới đầu chuyển sang Gitlab, mình gặp 3 khó khăn chính:
  • Không kiếm ra cái nút để approve merge request (MR): nhiều thông tin quá 😞. Mà mấy cái nút này nó không có cố định (sticky) khi scroll nên kéo lên kéo xuống một hồi là phải đi kiếm lại cái nút.
  • Cái nút để approve 1 cái merge request nó thay đổi trạng thái hoài: Lúc chưa có ai approve thì nó có màu nền xanh dương; còn lúc có người khác approve rồi thì nó nền trắng, viền xanh dương, ghi chữ “approve additionally”. Đứng dưới góc nhìn người dùng, mình méo quan tâm là “additionally” hay không. Mình chỉ muốn approve cái merge request và muốn đảm bảo là mình đã bấm đúng nút.
  • Nhấn nhầm nút: khi đã có người approve MR rồi, cái nút approve nó chuyển sang nền trắng viền xanh, còn cái nút merge lúc đó có nền xanh lá cây. Lướt qua xung quanh thì cái nút merge đó là có CTA mạnh nhất. Mình theo thói quen, cứ đinh ninh cái nút xanh xanh là cái nút approve. Nhấn cái phập, thế là merge cái MR của người ta luôn 😂. Cái này mình bị 1-2 lần mới quen ak…
    “Ba cái đồ cẩu thả” - Ừm, mấy người cứ phán xét tui đi 👊. Nhưng làm theo quán tính mà bị sai như thế này ngụ ý rằng cái UX chưa được tự nhiên cho lắm.

3 Điều mình khá hài lòng về Gitlab chính là CI/CD support. Bản thân mình thấy Gitlab CI/CD khá là xịn xò. Hồi trước khi project được host trên Github thì team xài Jenkins. Khi chuyển qua Gitlab thì thấy khả năng customization cao hơn hẳn. Mình cũng sẽ cho feedback tương tự khi so sánh giữa một bên thứ 3 như Bitrise và Gitlab. Mặc dù chưa dùng hết những tính năng của Gitlab CI/CD mình thấy cũng đã làm được đủ thứ rồi. Đấy là chưa kể do đặc thù platform (iOS) nên mình chưa khai thác nhiều tính năng “thông dụng” (vd. hổng xài được Docker flow cho mấy jobs liên quan đến iOS vì các tác vụ này chạy trên darwin kernel còn Docker thì yêu cầu linux kernel). Vì khả năng hỗ trợ cao của Gitlab CI/CD nên mình rất hay nghía mấy trang documentation của mấy bản. Trang mà mình hay tới lui nhất là https://docs.gitlab.com/ee/ci/yaml/. Lâu lâu coi xem bản release mới của Gitlab có cái nào hay.

4 Nói về preferences về CI/CD setup thì cũng có 2 trường phái chính:

• Trường phái thứ nhất thích những setup dạng kéo thả (drag-and-drop). Thường sẽ có 1 cái web interface để config workflow. Ví dụ đối với iOS thì nhập upload cái certificate và provisioning profiles lên cái web đó,rồi nhập cái build configuration vào là Debug hay Release…
• Trường phái thứ nhì thích những setup đòi hỏi mình phải định nghĩa workflow bằng code mà không có web interface kéo thả như trên. Thường với những trường hợp này cần viết thêm tí xíu code.

Cái này cũng tương tự như 2 trường phái mần UI trong iOS: bằng code thuần hay bằng interface builder (tức storyboard/xib). Vấn đề tương tự nên câu trả lời cho câu hỏi “chọn cái nào bây giờ?” cũng tương tự: tuỳ quy mô dự án, quy mô team, yêu cầu phần mềm…. Riêng mình, mặc dù không chê bai hay phán xét trường phái nào nhưng mình có xu hướng theo trường phái thứ nhì. Vì sao? Vì code như vậy đem lại cho mình cảm giác là mình đang chơi với nó hơn… Và với code thì dễ customize hơn, dễ cheat hack hơn.

…

Thôi tản mạn đến đây thôi… Về CI/CD (cho iOS) thì sẽ có những bài viết khác.