Git,Jenkins,Dockerの勉強順について

Git, Jenkins, Dockerの勉強をし、Javaでアプリ開発などを複数人で行いたいと考えております。

ざっくりとした質問で申し訳ございませんが、上記3つの勉強をする順番は
Git→Jenkins→Dockerの順番はしっくり来ますでしょうか？
正解はないかと思いますが、皆さまの意見をお聞かせ頂ければ幸いです。

2022/01/06 03:24

>問題・課題が含まれていない質問 teratailは困っている人の質問を解決するサービスです。そのため、漠然とした興味から票を募るような質問や、意見の主張をすることを目的とした投稿は推奨していません。正解がないと分かっているならここで論じた所で時間の無駄なので出来るものから学んでいけばいいと思います。

行動規範の内容に同意します

回答1件

ベストアンサー

明確な正解があるので回答します。
Git -> Docker -> Jenkinsの順番となります。

まずGitが最優先である理由から
一応Gitの競合であるMercurialやSubversionがありますが、
まぁGitの代わりにそれらをわざわざ採用するほどではなく、流行もGit一強状態なので腐りません。

また複数人開発の手戻りへのダメージを考えると
リポジトリを作って管理できる何かしらのツールは必須であり、
緊急性が高くお話にならないので真っ先にGitを学習・導入すべきです。

更にGitHub等のホスティングサービスにリポジトリを預け、
GitHub Flow等のブランチ運用ルールを学習し
プルリクエストを扱う開発手法を身に着けましょう。

まぁ、Gitの基本的なコマンドを一通り使えるだけで十分です。

clone: GitHub上でプロジェクトを作ってそれを複製して落としてくる

これによりinitを覚える手間がなくなる

pull: リモートリポジトリから最新の情報を落としてくる
branch: 新しいブランチを生成する
checkout: ブランチの移動
status: 現状の確認
add: 対象ファイルをステージに上げる
commit: ステージに上げたファイルでコミット履歴を生成する
push: ブランチをリモートブランチに保存する

次に何故DockerがGitと比べて一段回落ちるのか？
それはDockerの存在理由から紐解けばわかります。

作業者と本番環境で動作するマシンは異なります。
それにより本番環境で発生する不具合が、作業者のマシンで再現しなかったり
作業者のマシン同士でも不整合が出る等の問題がありました。

なので本番環境で仮想マシン(VirtualBox)を立ち上げてそこでサービスを提供すれば良いのでは？
という発想や需要自体はありました。
そうすれば作業者間・本番環境間で動作するマシンの環境はすべて統一され、同じ挙動を担保できるからです。

しかし、仮想のLinuxマシンを新しく立ち上げるのはPC全体にかかる負荷が大きく
マシンの処理性能を最大限Webサーバプログラム等に割きたいわけで、
本番環境で仮想マシンを立ち上げるなんてアホかとなるわけです。

そしてオーバーヘッドを極限まで抑えて
本番環境でも動作しうる仮想マシンとして登場したのがDockerです。
実装から紐解くと「仮想マシンとは？」という感じですが、その辺のコンテナの仕組みとかはおいおい勉強していきましょう。

そんなDockerは今すぐ必要ですか？
MySQL等のサーバーが利用したいケースならば今すぐ欲しいかもしれませんね。
「利用させて頂く立場」であるほんの触りだけ勉強する程度に止め
Gitを使ったシステム構築を優先させましょう。

最後にJenkins
代替手段の候補はGitHub Actions、CircleCI、Droneあたりとなり
Jenkinsは埋もれがちといえるでしょう。
Gitとは違い別に使いたきゃ使えば良いレベルなので無理して代替手段に行く必要はありません。

さて、これらのツールにだいたい共通しているのは
「webhookを利用してCI/CDを実現するための手段」であるということです。

GitHub等のGitリポジトリホスティングサービスでは
リポジトリにコミット、マージ、プルリクエスト等が行われた時
HTTPリクエストを発射してお伺いを行うWebhookという機能が存在します。

GitHubの類似サービスであるGitLabやBitBucketにも存在する事が確認できますね。

んで、このWebhookで何をしたいか？

自動テストはちゃんとしているのかい？
フォーマッターで独りよがりなコードにならないようにしてるかい？
Lintツールで変数等の対応はちゃんと確認したかい？

こういうのをチェックしたいわけです。
その上でmasterブランチにマージされたらソースコードをコンパイルして本番環境へ反映(デプロイ)して欲しい。

Jenkinsは保存したシェルスクリプトを叩けるようにしたというものなので、
Webhookに極度に依存しててWebhookがなきゃ何もできないゴミ……というわけではありません。
しかし、どのみち簡単に夢のCI/CD生活を実現してくれるツールではなく
自分でシェルスクリプトを作って想定した動作をしてくれるようにメンテし続ける必要があります。

そしてJenkinsの役割を考えた場合、
Gitフックのpre-commitで多くの要望が満たせるし、自動デプロイもスクリプト組んでそれ叩けば実現出来るじゃんって話ですよ。
コマンドラインでLinuxを自在に操作できるとかそういうのが先です。

シェルスクリプトファイルを手渡しで共有するとかもう辞めたい。
どっかに自分達だけが使えるサーバ立ててアウトソーシングしようぜ。
こういうプロジェクトが進展した段階で導入するツールであるJenkinsが今そんなに必要ですか？
いいえ、緊急性は最も低いので優先順位は最低です。

投稿2022/01/06 05:10

編集2022/01/06 05:13