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

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

開発チーム発足時に最初にやったことを備忘録も兼ねて記載していこうと思います。
# ブランチ戦略の決定
発足時は下記のようなブランチ戦略で開発を始めました。
タスク管理にはJiraを使用していたのでGitHub連携機能を使用し, 開発ブランチについてはチケット番号をそのままブランチ名にして管理していました。
![スクリーンショット 2024-03-10 23.52.58.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1550392/7e085709-af9b-7df1-43b1-9c754d267ff8.png)

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

  branch CH-YYYY
  checkout CH-YYYY
  commit
  commit
  checkout main
  merge CH-YYYY
  checkout main
```
# Pull Requestの設定
上記のブランチ戦略の項で記載したように, 各機能毎にbranchを着るのでPull Request(以下, PR)を頻繁に作成することになります。コードの品質保つため可読性の高いPRを書く必要があります。本チームでは下記の設定をPRに行いました。
## semantic-pull-requestの導入
PR作成時に, PRのタイトルが[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)に従った形式になっているかを判定するworkflowを導入。
これで過去のPRの検索が楽になります。
また
```yaml
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には下記のような種類があるようです。[リンク](https://github.com/commitizen/conventional-commit-types/blob/master/index.json)
```json
{
  "$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も見返しやすくなります。
導入方法は[こちらの記事](https://qiita.com/atsutama/items/03753925762fd094ec9c)を参考にしました。

実際に開発で使用したテンプレートはこちら
```markdown
## 概要
- 
- 

## 詳細
- 
- 

## 確認したこと
- 
- 

## JIRAチケット


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

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


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

```

またlaneには`certificates`をFastFile内で定義し, 各環境の証明書をまとめて取得するようにしました。
```　 m: 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向け

https://docs.fastlane.tools/actions/deliver/#deliver

- Google Play Store向け

https://docs.fastlane.tools/actions/supply/

- App Distribution

https://github.com/firebase/fastlane-plugin-firebase_app_distribution

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

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

# 参考ページ
https://www.atlassian.com/ja/software/jira

https://www.conventionalcommits.org/en/v1.0.0/

https://github.com/commitizen/conventional-commit-types/blob/master/index.json

https://qiita.com/atsutama/items/03753925762fd094ec9c

https://docs.fastlane.tools/