はじめに

今年度に自身のキャリアとして初めて，新規モバイルアプリケーションの開発にチームビルディングから参加しました。

開発チーム発足時に最初にやったことを備忘録も兼ねて記載していこうと思います。

ブランチ戦略の決定

発足時は下記のようなブランチ戦略で開発を始めました。
タスク管理にはJiraを使用していたのでGitHub連携機能を使用し, 開発ブランチについてはチケット番号をそのままブランチ名にして管理していました。

ブランチ名	役割
main	マスターブランチ　このブランチは必ず動く
feature(CH-XXXX/CH-YYYY)	開発用ブランチ　チケット名をそのままブランチ名に
release	リリースブランチ　codeFix時に作成するブランチ

Pull Requestの設定

上記のブランチ戦略の項で記載したように, 各機能毎にbranchを着るのでPull Request(以下, PR)を頻繁に作成することになります。コードの品質保つため可読性の高いPRを書く必要があります。本チームでは下記の設定をPRに行いました。

semantic-pull-requestの導入

PR作成時に, PRのタイトルがConventional Commitsに従った形式になっているかを判定するworkflowを導入。
これで過去のPRの検索が楽になります。
また

name: "Lint PR Title"

on:
  pull_request:
    types:
      - opened
      - edited
      - synchronize

permissions:
  pull-requests: write

jobs:
  main:
    name: Validate PR title
    runs-on: ubuntu-latest
    steps:
      - uses: amannn/action-semantic-pull-request@v5
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

また, Conventional commitsのindexには下記のような種類があるようです。リンク

{
  "$schema": "./index.spec.json",
  "types": {
    "feat": {
      "description": "A new feature",
      "title": "Features"
    },
    "fix": {
      "description": "A bug fix",
      "title": "Bug Fixes"
    },
    "docs": {
      "description": "Documentation only changes",
      "title": "Documentation"
    },
    "style": {
      "description": "Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)",
      "title": "Styles"
    },
    "refactor": {
      "description": "A code change that neither fixes a bug nor adds a feature",
      "title": "Code Refactoring"
    },
    "perf": {
      "description": "A code change that improves performance",
      "title": "Performance Improvements"
    },
    "test": {
      "description": "Adding missing tests or correcting existing tests",
      "title": "Tests"
    },
    "build": {
      "description": "Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)",
      "title": "Builds"
    },
    "ci": {
      "description": "Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)",
      "title": "Continuous Integrations"
    },
    "chore": {
      "description": "Other changes that don't modify src or test files",
      "title": "Chores"
    },
    "revert": {
      "description": "Reverts a previous commit",
      "title": "Reverts"
    }
  }
}

Pull Requestテンプレートの設定

PRを作成する際に指定されたフォーマットや情報を提供するためのテンプレートを設定しまう。テンプレートの使用によりレビュアーはPRの目的や変更点を理解しやすく, また過去のPRも見返しやすくなります。
導入方法はこちらの記事を参考にしました。

実際に開発で使用したテンプレートはこちら

## 概要
- 
- 

## 詳細
- 
- 

## 確認したこと
- 
- 

## JIRAチケット


## チェック項目
- [ ] マージ先は正しいか
- [ ] 修正差分に過不足はないか

証明書の管理設定(iOS)

iOSアプリのチーム開発を行うにあたって, 問題になるのが証明書の管理です。証明書発行のプロセスは非常に面倒で手間がかかります。
そこで本チームではfastlane matchを使用して証明書の共有管理を行うこととしました。

MatchFile

// 証明書を管理する開発チームメンバーがアクセス可能なprivate Reositoryへのリンクを指定
git_url("XXXX.YYYYYYY.git")
// 証明書の管理にはgitを使用した
storage_mode("git")

またlaneにはcertificatesをFastFile内で定義し, 各環境の証明書をまとめて取得するようにしました。

FastFile(抜粋)

platform :ios do
  lane :certificates do
    match(type: "development",readonly: true, app_identifier: ["com.project.dev"])
    match(type: "appstore",readonly: true, app_identifier: ["com.project","com.project.stg"])
  end
end

補足

fastlaneはアプリストアへの申請やApp Distributionへの配信にも使用しました。

App Store向け

Google Play Store向け

App Distribution

おわりに

細かい準備については他にもあったのですが, 大きなトピックとしては以上の4つかと思います。

CI:CD環境の構築にはfastlaneが必要不可欠ですね。本チームはFlutterでの開発でしたが問題なく使用できました。（そりゃそうだ）

開発チーム発足時に最初にやったこと