Đánh giá sau khi migration từ Jira sang GitLab và những điều rút ra

• Đánh giá về một dự án mã nguồn mở thực hiện migration từ Jira sang GitLab
• Động lực
  • Tin tức sản phẩm Jira Server sẽ ngừng hỗ trợ từ ngày 15 tháng 2 năm 2024
  • Các lựa chọn thay thế có thể chọn: Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub, v.v.
  • Những người đang dùng Jira Server phải làm sao? Hay là thử tạo một dự án migration sang GitLab?
• Tình hình tính năng migration Jira → GitLab
  • Trong GitLab, có thể sao chép title, description, label của issue Jira
  • Các metadata còn lại được đưa vào description
  • Cung cấp UI để ánh xạ Jira User sang GitLab User
• Các hạn chế của migration Jira → GitLab
  • Bắt buộc phải cấu hình Jira Integration
  • Chỉ cung cấp Jira API v3
  • Jira và GitLab dùng cú pháp khác nhau nên không thể migration chính xác hoàn toàn
    • Trong description, Heading 1, Heading 2, Heading 3 được chuyển thành Numbered, SubNumbered, SubNembered 2
    • GitLab dùng cú pháp Markdown, còn Jira dùng chuẩn riêng là ADF(Atlassian Document Format), nên phát sinh khác biệt
  • issue type, priority, label cũng không được migration chính xác hoàn toàn
• Hướng đi của dự án migration nội bộ
  • Mục tiêu:
    • Ra quyết định epic của Jira sẽ đi đâu, issue sẽ đi đâu
    • Thực hiện migration cụ thể để xác định các trường issue của Jira như title, description, label, component... sẽ đi vào trường nào của GitLab
  • Khi chuyển epic Jira sang epic GitLab, cho người dùng quyền tự do quyết định sẽ migration thành sub-epic trong sub-group hay thành epic ở nhóm cấp trên
  • Issue thì được migration thành issue
  • Giới hạn:
    • Muốn migration sub-task thành task nằm dưới issue của sub-task, nhưng GitLab không hỗ trợ Task API
    • Jira có quá nhiều trường
      • Các tính năng đơn giản như description, label, component được GitLab hỗ trợ nên có thể migration
      • But!!! các trường liên quan đến time tracking, bảo mật thì GitLab không hỗ trợ nên không thể migration
  • Thiết kế cuối cùng
    • Dự án Jira → dự án GitLab
    • Epic Jira → epic GitLab
    • Issue Jira → issue GitLab
    • title, description, version, story point, resolution của Jira được ánh xạ nguyên trạng sang GitLab
    • resolution của Jira → closed của GitLab, story point của Jira → weight của GitLab
    • issue type, component, status, priority của Jira → migration bằng label, scoped label của GitLab
    • Cũng phát triển cả custom field
    • description được parse toàn bộ định dạng bằng biểu thức chính quy, chuyển nội dung sang Markdown rồi migration
  • Kết quả dự án
    • Migration chế độ thuần Jira là khá dùng được
    • Nếu bỏ plugin và automation thì migration hoạt động tốt
    • Phần lớn được ánh xạ bằng GitLab Label
    • Tạo epic ở nhóm cấp trên của mục tiêu
    • Các liên kết issue được nối trong Jira cũng được migration sang GitLab
    • Jira wiki markup được chuyển đổi bằng Markdown converter
    • Cũng thêm attachment, comment vào issue
    • Nếu tạo quá nhiều custom field thì sẽ khó khi migration
  • Những điểm làm tốt
    • Làm bản cloud trước, rồi bổ sung thêm bản cho server
    • Chỉ cần cấu hình mapping cho custom field là có thể migration phần lớn nội dung
    • Tổ chức xử lý song song hợp lý để migration nhanh hơn hơn 3 lần so với khi không làm vậy
    • Quản lý cấu hình theo dạng YAML để phù hợp với xu hướng
    • Mở mã nguồn để ai cũng có thể migration
    • Phát hành gói qua Brew
  • Những điểm cần cải thiện
    • Khi migration từ Jira Server
      • Cần bổ sung mapping cho sprint
      • Không có cách nào cho trường Cascade
    • Khi migration từ Jira Cloud
      • Cần kiểm thử nhiều tình huống thực tế như migration dữ liệu liên quan đến plugin
  • Trang của dự án mã nguồn mở tương ứng:
    • https://github.com/infograb/j2lab
    • https://gitlab.com/infograb-public/J2Lab