Photoruction工事中!

Photoructionの開発ブログです!

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

こんにちは!今年の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, ...のように分けていく。

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

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

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

リポジトリ事前設定

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

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

  1. "settings" → "Branches"と選択

    f:id:photoruction_tech_blog:20211217105033p:plain
    github_setting01

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

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

    f:id:photoruction_tech_blog:20211217105127p:plain
    github_setting02

  3. "Save Changes"(作成時は"Create")を選択して終了

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

開発環境のコンテナ化

コンテナ化と実装理由

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

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

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

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

dockerでのコンテナ化実装

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

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

  • Dockerコンテナーの概要

  • pc内にDocker Desktopをインストールする

  • 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

corporate.photoruction.com