Zenn
🗂️

【エンジニア初学者】開発ワークフローとツール

に公開
Docker
GitHub
ソフトウェアテスト
Spring Framework
ソフトウェア開発
tech

ソフトウェア開発では、効率的で品質の高いプロダクトを作るために、いろいろなツールやワークフローが活用されています。
この記事では、その中でも特に重要なDocker・Git・GitHub Actions・テストについて、エンジニア初学者が学んだことをアウトプットしています。

Dockerとその関連ツール

Dockerとは

Dockerは、アプリケーションをコンテナという単位で実行できるプラットフォームです。
従来は「アプリは自分のパソコンでは動くのに、他の人の環境だとうまく動かない…」という問題がよく起きていました。

コンテナとは

アプリが動くために必要なもの(コード・ライブラリ・設定など)をひとまとめにした “「アプリと動作に必要なもの一式」の箱” のようなもの。
この「箱」によってどの環境でも同じように動作するというメリットがあり、
開発者のパソコンと本番サーバーで動作が違う…というトラブルを減らせます。

例えばこんな場面で便利です。

  • 開発環境（自分のPC）と本番環境（サーバー）の差によるバグを防ぐ
  • チーム全員が同じ環境で開発できる

Docker Compose

Docker Composeは、複数のDockerコンテナをまとめて管理するツールです。
例えば「Webアプリ本体」「データベース」などの複数のコンテナを一緒に立ち上げられます。
これらを一つひとつ起動するのは面倒ですが、Composeを使えば
docker-compose upの1コマンドで全部立ち上げられます。
docker-compose.yml には各コンテナの設定を書きます。

docker-compose.ymlの例

version: "3"
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data
volumes:
  db-data:

主な設定項目の例

  • ports：
    ホスト(自分のPC)とコンテナ間で使うネットワークポートの指定。
    例："8080:8080" → ホストの8080番ポートとコンテナの8080番ポートを繋ぐ。

  • depends_on：
    「Aが動いてからBを起動する」といった依存関係を設定。

  • volumes：
    データ永続化のため、コンテナが使うデータ保存領域の指定。

バインドマウントとボリュームマウントの違い:

  • バインドマウント：
    ホストPCのフォルダをコンテナに共有。
    開発中のコード修正が即時反映され便利。

  • ボリュームマウント：
    Docker専用の領域を使用。
    データを消さずにコンテナを入れ替え可能。

Dockerfile

Dockerfileは、コンテナの作り方を指示するレシピファイルです。
Dockerfileの例

FROM node:18
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

主な命令

  • FROM： ベースとなるDockerイメージを指定

  • WORKDIR： 作業ディレクトリを設定

  • ENV： 環境変数を設定

  • RUN： ビルド時にコマンド実行

  • COPY： ホスト側のファイルをコンテナにコピー

GitとGitHub Actions

Gitは、ソースコードの変更履歴を管理する「バージョン管理システム」です。
簡単に言うと「コードのタイムマシン」で、過去の状態に戻したり、チームで作業を分担したりできます。
GitHubは、そのGitリポジトリ(コードの置き場)をインターネット上でホスティングするサービスです。

Gitの基本コマンド

  • git fetch：
    リモートリポジトリ(GitHubなど)の最新情報を取得。
    ローカルブランチにはまだ反映されない。

  • git checkout -b <新しいブランチ名>：
    新しいブランチを作成して切り替え。

  • git reset --hard <ブランチ名>：
    現在の内容を指定ブランチの状態に完全リセット(※元に戻せないので注意)

  • git push --force-with-lease：
    リモートに強制プッシュ。
    ただし他人の変更があればブロックされる安全策付き。

マージの種類

  • Merge Commit：
    ブランチ統合時に「どのブランチから来たか」が残る。
    履歴はわかりやすいが複雑になりがち。

  • Squash Merge:
    複数コミットを1つにまとめてマージ。
    履歴はスッキリ。

  • Rebase Merge:
    変更を最新状態に再適用し、履歴を直線に整理。
    便利だが既に共有されたブランチに使うと危険。

GitHub Actionsとは？

GitHub Actionsは、GitHubリポジトリで自動化を行うツールです。

例：
コードをプッシュしたら自動でテスト・ビルド・デプロイを実行

これにより以下が実現できます

  • CI (Continuous Integration)：
    プッシュ時に自動テスト。

  • CD (Continuous Deployment)：
    問題なければ本番環境に自動デプロイ。

ワークフローは YAML形式 のファイルで記述します。

ソフトウェアテストとデバッグ

テストの種類

ホワイトボックステスト：
コード内部の構造まで見てテスト。

ブラックボックステスト：
内部は見ず、入力と出力だけでテスト。

コードカバレッジ

コードカバレッジは「テストがどれだけコードを網羅したか」の指標です。

  • C0(ステートメントカバレッジ)： 各行が1回は実行されたか

  • C1(ブランチカバレッジ)：if文など全ての分岐が実行されたか

デバッグの基本

ブレークポイント：
プログラムを一時停止し、変数の中身などを確認できるポイント。

ステップイン：
プログラムを1行ずつ進めながら実行。

テスト用アノテーション(Spring Frameworkの場合)

  • @MockBean：
    本物の代わりに「モック(偽物)」を使う。
    データベース接続などをシミュレート可能。

  • @SpyBean：
    本物のオブジェクトを監視・一部だけ差し替え可能。

  • Mockito.when()：
    モックの動作を設定。

  • Mockito.verify()：
    特定のメソッドが呼ばれたか検証。

  • @Disabled：
    テストを一時的に無効化。

フィードバック歓迎です

誤りや改善点があれば、ぜひコメントやフィードバックをいただけると嬉しいです。

Discussion