10 ポイント 投稿者 ironlung 2023-10-24 | まだコメントはありません。 | WhatsAppで共有
  • JiraからGitLabへ移行するオープンソースプロジェクトの振り返り
  • きっかけ
    • 2024年2月15日をもってJiraサーバー製品のサポート終了が発表されたこと
    • 選択可能な代替案: Pivotal Tracker, IBM Engineering Requirements Management DOORS Next, Rally Software, GitLab, ServiceNow Agile Development, GitHub など
    • Jiraサーバーを使っていた人たちはどうすればいいのか? GitLabへ移行するプロジェクトを作ってみようか?
  • Jira → GitLab移行機能の現状
    • GitLabではJiraイシューのtitle、description、labelをコピー
    • そのほかのメタデータはdescriptionとして取り込む
    • Jira UserをGitLab UserにマッピングするUIを提供
  • Jira → GitLab移行の制約事項
    • Jira Integrationの設定が必須
    • Jira API v3のみ提供
    • JiraとGitLabでは使用する文法が異なるため、正確には移行されない
      • description内の「Heading 1」「Heading 2」「Heading 3」が「Numbered」「SubNumbered」「SubNembered 2」に移る
      • GitLabはMarkdown記法を使用し、Jiraは「ADF(Atlassian Document Format)」という独自仕様を使っているために生じる違い
    • issue type、priority、labelも正確には移行されない
  • 社内移行プロジェクトの方向性
    • 目標:
      • Jiraエピックをどこへ移し、イシューをどこへ移すべきかの意思決定を行う
      • title、description、label、componentなど、JiraイシューのフィールドをGitLabのどのフィールドへ移すかを具体化して移行を進める
    • JiraエピックをGitLabエピックへ移す際、サブグループ内のサブエピックとして移行するか、上位グループ内のエピックとして移行するかをユーザーが決められるようにして自由度を持たせた
    • イシューはイシューとして移行するようにした
    • 限界:
      • サブタスクもサブタスク配下のイシュー内タスクとして移行したかったが、GitLabのタスクAPIが対応していない
      • Jiraにはフィールドが多すぎる
        • description、label、componentのような単純な機能はGitLabでも対応しており移行できる
        • しかし time tracking や security 関連フィールドはGitLabで対応しておらず移行できない
    • 最終設計図
      • Jiraプロジェクト → GitLabプロジェクト
      • Jiraエピック → GitLabエピック
      • Jiraイシュー → GitLabイシュー
      • Jiraのtitle、description、version、story point、resolutionはGitLabにそのままマッピング
      • Jira resolution → GitLab closed、Jira story point → GitLab weight
      • Jira issue type、component、status、priority → GitLab label、scoped labelを使って移行
      • custom fieldも開発
      • descriptionはフォーマットを正規表現で全てパースし、内容をMarkdownに変換して移行
    • プロジェクトの結果
      • Jiraの素のモードを移行するのは実用的
      • プラグインやオートメーションを除けば移行はうまくいく
      • ほとんどをGitLab Labelでマッピング
      • ターゲット上位グループにエピックを作成
      • Jiraで関連付けられたイシューリンクもGitLabへ移行
      • Jira wiki markupはMarkdownコンバーターで変換
      • イシューにattachment、commentも追加
      • custom fieldをたくさん作ると移行時に難しくなる
    • うまくいった点
      • まずクラウド版を作り、その後サーバー用を追加した
      • custom fieldのマッピングだけ設定すれば、大半は移行できる
      • 並列処理を適切に構成し、そうしなかった場合より3倍以上速く移行できるようにした
      • トレンドに合わせてYAMLベースで設定を管理した
      • オープンソースとして誰でも移行できるようにした
      • Brewでパッケージ配布した
    • 改善すべき点
      • Jiraサーバーから移行する場合
        • スプリントのマッピングを追加で行う必要がある
        • Cascadeフィールドには方法がない
      • Jiraクラウドから移行する場合
        • プラグイン関連データの移行など、多数の実際のケースでテストが必要
    • 該当オープンソースプロジェクトのページ:

まだコメントはありません。

まだコメントはありません。