こんにちは！今年の5月から株式会社PhotoructionでAIエンジニアとしてインターンをしている渡邉圭太郎です。 Photoruction Advent Calendar 2021の24日目の記事です。

はじめに

僕の所属するチームではパッケージ管理をgithubで行っていましたが、特に管理ルールはなくリポジトリの扱い方はメンバーによって異なっていました。加えて、CI/CDを積極的に行っていこうという意見がチーム内で上がっていました。特にチームの核であるAIモデルの精度向上などAI開発の方に時間を割きたいというメンバーが多かったからです。

そこで、この度チーム内でのパッケージ管理ルールを制定したのでその内容を一部紹介します。

ブランチ戦略

ブランチ戦略とは

ブランチ戦略とは、Git上でブランチを分けて作業を並行して行う際にそのブランチを計画的に作成し運用していくことである。定めておくことでチーム開発での開発の柔軟性とコードの一貫性という2点が確保できる。

Github Flow

ブランチ戦略自体はたくさん考案されているが、今回はGithub flowというブランチモデル（master, develop, 各topicごと...）を採用した。その内容を簡単に下図に示す。

f:id:photoruction_tech_blog:20211217104819p:plain — git flow

masterブランチを本番環境ブランチ、developブランチを開発環境とし、エンジニアが個々に開発を行う場合はbranch1, branch2, ...のように分けていく。

この運用方法では以下の基本ルールがある。

masterは常にデプロイ状態にする
masterから必ずtopicブランチを切りmasterに直接コミットすることがないようにする
ブランチは定期的にpushする
pull requestを用いてコードレビューを行う
コードレビューが完了したらすぐにmergeする

様々な記事を読むとこの他にもカスタムルールを制定している場合もあるようなので、ぜひ自チーム流にブランチ戦略を制定してみてほしい。

リポジトリ事前設定

前項で挙げたルールのうち1, 2そしてCIに関してはGithub リポジトリの設定項目から事前に制約をかけることができる。

今回は1例として、masterブランチへCIを成功したブランチのみmergeを許す方法を記載する。

"settings" → "Branches"と選択

github_setting01
"Branch protection rules"から"Add rule"を選択し、下図のように設定をする。

具体的には、リポジトリ管理者を含めmainブランチにおいてCIを成功させないとmergeできないように設定している。また、この設定によりmainブランチへの直pushも防いでいる。

github_setting02
"Save Changes"（作成時は"Create"）を選択して終了

また、他の設定項目については詳しくはこちらを参照。

開発環境のコンテナ化

コンテナ化と実装理由

コンテナ化とは、ソフトウェアのコードをライブラリやフレームワークなどの依存関係にあるすべてのコンポーネントとともにパッケージ化し、それぞれの入れ物、「コンテナ」に隔離することです。（コンテナ化とは）

また、開発環境のコンテナ化を行うと以下のことができる様になる。

チェックや改修の際の環境構築を楽になる
osのバージョン等に左右されずに開発を行える

以上の理由から開発環境のコンテナ化を行うこととなった。

dockerでのコンテナ化実装

今回コンテナ化にはDockerを用いて行う事になった。そこで実際の実装例を紹介する。

なお、Dockerについての事前知識については以下を参照。

Dockerコンテナーの概要
pc内にDocker Desktopをインストールする
- Dockerのインストール手順

Dockerfileとdocker-compose.ymlを用意する

フォルダ構成

 ├── docker-compose.yml
 ├── Dockerfile
 ├── README.md
 └── src

Dockerfile

 FROM python:3.8

 ENV APP_PATH=/code \
     PYTHONPATH=.
 #　開発物のソースコードはcodeデイレクトリ下に配置する

 WORKDIR $APP_PATH

 RUN apt-get update && \
     apt-get upgrade -y && \
     pip install poetry
 # コンテナのセットアップ

 COPY . .

 RUN poetry install 
 #　必要なパッケージ等をインストールする

 EXPOSE 8080

docker-compose.yml

 version: '3.8'
 # 使用するDockerEngineリソースに適応するバージョンを指定する。

 services:
   test_src:
     container_name: test_container

     build:
       context: .
       dockerfile: ./Dockerfile
     ports:
       - "8080:8080"
         tty: true
     volumes:
       - ./src/:/code/src
       - ${PIP_CACHE_DIR_WORKER:-cache-test}:/root/.cache

 volumes:
   cache-test:

なお、さらに詳しい引数等の内容に関しては、以下のドキュメントを参照。

必要なファイルの準備ができたらDockerfileとdocker-composeを使用してコンテナを構築する

 docker-compose up -d --build test_src
 # イメージのビルド

 docker exec test_container poetry install
 #　必要なパッケージのインストール

 docker-compose up -d
 #　すべてのコンテナの起動

これだけで環境のコンテナ化が完了する。

あとは、各々開発をゴリゴリすすめる。

まとめ

本記事では、実装例を紹介することを目的としたため基礎知識について深く解説できなかったので、その部分についての詳細は参考文献を参照してください。また、こうした方がより使いやすい等ありましたらぜひ教えて下さい！

パッケージ管理ルールを制定したことでチーム開発内で無駄に考えることが減ったと感じます。より開発自体に注力できる様になったのは良いことであると感じました。

また個人的には、チーム開発に関することは個人で行うには限界があったので、インターンという立場でこのようなことが学べたのはとても勉強になりました。これからも開発を頑張っていきたいと思います！

参考文献

株式会社フォトラクションでは一緒に働く仲間を募集しています

corporate.photoruction.com

Photoruction工事中！

Photoructionの開発ブログです！

パッケージの管理ルールを制定してみた