開発環境を改善するためにチームに提案して実践したこと

## 導入

### 何について話すのか

開発環境を改善して、効率化することでアプリケーション開発に注力するため行った（行っている）取り組みについてお話します。

本記事はQmonus Value Streamの投稿キャンペーン記事です。

### 想定読者

- レガシーな環境を改善している（していきたい）人
- 開発環境改善のアイデアが欲しい人
- CI/CDやDevOpsよりな仕事に関わる人

### どんな人が書いているか(自己紹介)

- 3年目のエンジニアでバックエンドを中心に担当（最近インフラも担当するようになりました）
- メインで扱う技術はPHP・TypeScript・AWS
- アプリケーション開発とAWSインフラ構築を担当する
- 受託開発が中心の企業に従事

## 記事で触れる取り組み（取り組んだ順）

1. Dockerの導入
2. テスト・静的解析の導入
3. CI/CDの導入・整備による効率化
4. Gitフローの変更・整備・周知
5. フロントエンド側へTypeScript・Vueの導入
6. AWSサービスの活用

## Dockerの導入

### 背景

Docker導入前はwinscpというツールを利用してLinuxサーバに直接SFTPでファイルをアップロードし、Linuxサーバーに割り当てられたローカルIPアドレスをブラウザでたたいてアクセスして動作確認を行う環境でした。この環境は以下のような問題を抱えていました。

### 課題

- **開発環境構築の手間**：LinuxサーバーにPHPの実行環境を構築する手間が必要で、新メンバーのオンボーディングが遅延しました。
- **環境差異**：開発環境、検証環境、本番環境でPHPやミドルウェア等のバージョンが異なり、動作確認が一貫しないことが多々ありました。
- **再現性の低さ**：サーバ構築の再現性が低く、環境によって動かないコードが存在しました。
- **改善の難易度**：上記の要因によってアップデートの難易度・工数が跳ね上がり、改善に着手しにくい状況でした。

### Docker導入後のメリット

- **環境の統一と再現性の向上**：Dockerを用いることで、全員が同じ開発環境を利用できるようになり、環境差異による問題が解消されました。
- **スクラップ＆ビルドの容易化**：開発環境の作り直しがしやすくなり、検証作業等がスムーズに行えるようになりました。これにより、改善活動がやりやすくなりました。
- **開発サーバーの不要化**：開発用途のサーバーを立ち上げて共有する必要がなくなり、ファイルのアップロードの度に発生するほかの作業者への確認などの質問がなくなりました。
- **新メンバーのオンボーディングの迅速化**：新メンバーが迅速に開発環境を整備できるようになり、生産性が向上しました。

## テスト・静的解析の導入

### 背景

古めのPHPを利用していた背景もあり、コードの品質に課題がありました。これを解決するために、テストと静的解析を導入しました。

### 導入したツール

- **PHPStan(Larastan)**：静的解析ツールとして利用。コードの問題を早期に発見するのに役立ちました。
- **PHPcs**：コーディング規約に沿ったコードを書くためのツール。チーム全体のコード品質向上に貢献しました。
- **PHPmd**：メンテナンス性向上のためのコード解析ツール。
- **PHPUnit**：単体テストフレームワーク。自動テストの導入により、品質保証を強化。
- **ESLint・Prettier**：JavaScriptとTypeScriptのコード品質を保つためのツール。統一されたコードスタイルを保つことができました。

### 導入後の効果

- **早期発見と修正**：バグの早期発見と修正が可能になり、デバッグの手間が大幅に減少しました。
- **コードの可読性向上**：コードの可読性が向上し、他のメンバーがコードを理解しやすくなりました。
- **開発スピードの向上**：開発スピードが向上し、新機能の追加や改修がスムーズに行えるようになりました。
- **品質保証の強化**：自動テストにより、リリース前に問題を発見・修正できるようになり、品質保証が強化されました。

## CI/CDの導入・整備による効率化

### 背景

手動でのデプロイが主流で、ミスが発生しやすく、時間もかかっていました。これを解決するためにCI/CDを導入しました。

### 導入したツール

- **GitLab CI**：CI/CDパイプラインを構築し、コードの自動テストとデプロイを実現しました。
- **GitLab Runner**：テストコードが増えた段階で並列化するために導入しました。
- **AWS Codeシリーズ**：AWSの複数の環境へのデプロイを自動化しました。

### 導入後の効果

- **デプロイの安定化**：手動デプロイのミスがなくなり、デプロイ作業が安定しました。
- **品質保証の強化**：自動テストによる品質保証が強化され、デプロイ前の不安が軽減されました。
- **開発者の負担軽減**：デプロイ作業の自動化により、開発者がコア業務に集中できるようになりました。
- **迅速なフィードバック**：CI/CDパイプラインにより、迅速なフィードバックが得られるようになり、開発サイクルが短縮されました。

## Gitのブランチ戦略の変更・整備・周知

### 背景

AWS Codeシリーズを利用したCI/CDを整備するために、CI/CDに合わせたGitブランチ戦略を採用するように変更しました。

### 導入した施策

- **GitLabフローを参考にしたブランチ戦略を導入**：main, staging, productionに分割して環境別に分けたことで簡略化。
- **ドキュメントの整備**：Gitフローの手順書を作成し、新メンバーがすぐに参照できるようにしました。

### 導入後の効果

- **マージ作業の安定化**：マージ作業のミスが減少し、リリースが安定しました。
- **CI/CD構築の簡略化**：各ブランチの用途が明確になり、CI/CDの構築難易度が下がりました。

## フロントエンド側へTypeScript・Vueの導入

### 背景

従来は素のJavaScriptやjQueryで書かれていましたが、複雑化したり古くなってメンテナンスが困難になっていました。

### 導入した技術

- **TypeScript**：型を意識することで潜在的なバグの混入を防ぐ目的で導入。
- **Vue.js**：コンポーネントによってコードの再利用性に注目し、開発工数を削減するために導入しました。

### 導入後の効果

- **開発スピードの向上**：コンポーネントの活用によって開発スピードが向上し、機能の実装がスムーズになりました。

## AWSリソースの活用・効率化

### 背景

開発環境はDockerを入れていましたが、AWSで構築している検証環境・本番環境等はEC2に直接サーバー構築して運用を続けているため、スケーラビリティや運用コストに課題がありました。

今はこの課題の解決に以下の施策で取り組んでいます。

### 検証しているサービス

- **AWS CDK**：受託開発で複数のプロジェクトを立ち上げていますが、インフラ構成は似通ったものが多いため、再現性を高くし、AWSインフラ構築に対する工数を削減するためにIaCの導入を進めています。
- **Fargate/ECS**：EC2でホストしていたサービスを移行し、開発環境との差異を減らしたり、セキュリティ面や運用工数削減の観点から優位性があるためFargate/ECSの構成の導入を進めています。

### 期待している効果

- 運用コストの最適化
- 工数削減
- 工数の不足によって対応されにくい、セキュリティ面の脆弱性対応などへの着手

## メッセージ

Dockerの導入からレガシーな環境から脱却してコードを快適な環境で実装していけるようにするためにチームに提案を始めたのは1年半ほど前になります。
基本的にPHPとHTML/CSS/Javascriptが触れるくらいの技術レベルでしたが、提案していくために個人的な検証を重ねたり説明していくことである程度の技術力が身に付き、結果としてインフラ面にもかかわるようになりました。
もし、当時の自分のように技術力がなくても環境を改善していきたい気持ちのある方がこの記事を読んでいただいて、参考にしてくれていたらうれしいです。

## 結論

Dockerの導入が起点となり、複数の改善のための肝となりました。Dockerを導入することで、開発環境の一貫性と再現性が確保され、その結果、テストやCI/CDの導入、コード品質向上の取り組みがスムーズに行えるようになりました。また、Gitのブランチ戦略の整備やフロントエンドのモダナイズにより、チーム全体の開発効率が大幅に向上しました。最後に、AWSリソースの活用により、インフラのスケーラビリティと運用コストの削減が実現し、アプリケーション開発に注力できる環境が整いました。