概要
Lint, Build, JUnit等のCIをActions上で動かし、質を高める

タスク

• Lint系のCI導入
• BuildのCI導入
• JUnitのCI導入

概要

ログインメールアドレスから学生を絞れるので選択させる手順は不要だと考える。

概要
リーグ結果を確認して、手動でトーナメント出場チームを設定する手間がかかるので、リーグ結果よりトーナメント出場チームを自動で補完する機能

タスク

• 試合のチームを特定のリーグ・トーナメントの優勝チーム等との依存関係を追加できるようにする
• 検証

概要
審判から結果の紙を受け取って管理者がSPORTSDAYに入力していくのは無駄な手間が一つ増えるため、審判がweb appより結果を申告できるようにする。申告された結果は管理者が承認する形式にする。

タスク

• 審判箇所を文字列からteamエンティティにする
• 開始時間が近づいた審判の試合を返すエンドポイントの開発
• 試合結果を申告するエンドポイントの開発
• 試合結果を承認するエンドポイントの開発
• 検証

概要
ユーザ連携の際に全ユーザーを返すのはどうかと思うので、ユーザーだけでもフィルター可能にしておく。

概要

認可にロールを使う方法から権限を使う方法に切り替えていく

概要
テーブルの設計を見直す。
見直す余地のあるテーブルとして、トーナメントパス、ユーザー連携等がある。

概要

グループ分けはサブドメインで分ければいいからいらない

概要

tbls導入

概要
晴天時の場合、雨天時の登録データを削除する必要がある。
しかし、人的ミスで意図しないデータが消えるリスクが考えられるので、切り替えできる機能を実装すればいいと思う。

タスク

• TagsのCRUDを作成
• Tagの状態に応じてオブジェクト返すかを制御する
• 検証

概要
フロントエンドの実装を考えて、バックエンド側で外部キーをエンティティーに置き換えてレスポンスする

Refactor: Dependency Injectionを導入
DI,DDDを導入する際にこのissueが解決する

例：

{
  "id": 1,
  "name": "Team A",
  "usersIds": [
    1, 3
  ]
}

以下のようにusersに置き換える。

{
  "id": 1,
  "name": "Team A",
  "users": [
    {
      "id": 1,
      "name": "User A"
    },
    {
      "id": 3,
      "name": "User A"
    }
  ]
}

タスク

• Entity::serializable()関数を再設計or廃止して別のものにする
• DTOからレスポンスを作成
• レスポンスのJSONを直す

概要

トレーサビリティーを確保するために、ログを適切に設計する

タスク

• 仕様設計
• 実装

概要

ユーザーの権限などを各ノードでキャッシュする場合、うまく同期できないことが予想できる。
そこで一時的な共有キャッシュとしてRedisを活用する。

タスク

• 権限キャッシュ部分の取り除き
• Redisへキャッシュする
• クラスターで検証

概要

Roleを取り除いた状態では、認可ができていないので権限ベースの認可を追加する

タスク

• Permissionドメイン実装
• PermissionGroupドメイン実装
• 認可フロー(pipeline?)実装
• 検証

概要

ドメインがリファクタリングを通して変更されていくため一時的な識別方法としてチームタグ機能を設けることにした

タスク

• TeamTagドメイン追加
• エンドポイント追加

概要
管理者の負担を軽くするべく、各リソースをCSVに変換できる機能を実装する

タスク

• CSV変換機能

概要

集計が終わる前に結果がわかってしまうのはよろしくないので、残り試合数がある割合になれば503を返す

タスク

• コンフィグ周りを実装
• コンフィグ用のエンドポイント作成
• バックエンド側で503を返すか判定
• フロント側で503を検知して表示
• 検証

概要

審判の試合をわかりやすくするために、審判担当チームを文字列からチームに変更

タスク

• バックエンド実装
• フロントエンド実装
• 検証

概要

現在実装されている認証方法は、改善が必要だと考えられる。その要因としては、以下の２つが挙げられる。

• 特定のプロバイダー（現在はAzure AD）でしかログインが行えない点
• 本来ならプロバイダーのリソースサーバーへのアクセスで使用するためのトークンを、本システムの認証にも流用している点

OpenID Connectを用いた認証方法に移行を行う

タスク

• MicrosoftAccountsをUsersに統合
• 認証フローを修正
• 検証

概要

OpenID Connectに移行する際に取り除いたため、戻す

タスク

• 制限をかける

概要

Usersにプロフィール画像を直接埋め込むとフェッチにかかる時間が大幅に長くなるため、Imagesに保存してUsersにはurlとして保存する

タスク

• Imagesの改良
• UsersにImagesの外部キー挿入
• URL経由で画像ファイルを配信できるように変更
• ログイン時の非同期画像更新
• 検証

概要
Dependency Injectionを導入し可読性を向上させ、開発へ参加のハードルを下げることを目的とする。

タスク

• Linter導入
• 複雑な(汚い)コードのリファクタリング
• DI導入
• ドキュメント化

概要

Refactor: Dependency Injectionを導入
DI,DDDを導入する際にこのissueもついでに解決する

すべてのPodが正しくデータを同期できていない場合があるので再設計する。

原因として考えられるもの:

• Redisのメッセージを落としている
• DBが過負荷でトランザクションが複数回失敗し取得ができていない
  上にあげた以外に、考えられる原因はあるかもしれない。

完璧にデータを同期できるシステムを作る。かつ、DBに負荷の少ないシステムにする。

タスク

• 原因を調査する
• 設計
• 実装
• 検証