Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

今さら聞けない人のためのGit超入門

412 views

Published on

今さら聞けない人のためのGit超入門
3/13 ニフクラエンジニアミートアップ版

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

今さら聞けない人のためのGit超入門

  1. 1. 今さら聞けない人のための Git超入門 3/13 ニフクラエンジニアミートアップ版 日本仮想化技術株式会社 代表取締役社長兼CEO 宮原 徹(@tmiyahar) http://VirtualTech.jp
  2. 2. 自己紹介 • 本名:宮原 徹 • 1972年1月 神奈川県生まれ • 1994年3月 中央大学法学部法律学科卒業 • 1994年4月 日本オラクル株式会社入社 – PCサーバ向けRDBMS製品マーケティングに従事 – Linux版Oracle8の日本市場向け出荷に貢献 • 2000年3月 株式会社デジタルデザイン 東京支社長および株 式会社アクアリウムコンピューター 代表取締役社長に就任 – 2000年6月 (株)デジタルデザイン、ナスダック・ジャパン上場(4764) • 2001年1月 株式会社びぎねっと 設立 • 2006年12月 日本仮想化技術株式会社 設立 • 2008年10月 IPA「日本OSS貢献者賞」受賞 • 2009年10月 日中韓OSSアワード 「特別貢献賞」受賞 • ガンダム勉強会主宰・好きなモビルスーツはアッガイ 2
  3. 3. 3 『Software Desgin』で毎月 「宮原徹のオープンソース放浪記」連載中
  4. 4. 日本仮想化技術株式会社 概要 • 社名:日本仮想化技術株式会社 – 英語名:VirtualTech Japan Inc. – 略称:日本仮想化技術/VTJ • 設立:2006年12月 • 資本金:3,000万円 • 売上高:10,702万円(2017年7月期) • 本社:東京都渋谷区渋谷1-8-1 • 取締役:宮原 徹(代表取締役社長兼CEO) • 伊藤 宏通(取締役CTO) • スタッフ:9名(うち、7名が仮想化技術専門エンジニアです) • URL:http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築・運用サポート – OpenStackの導入支援・新規機能開発・運用サポート – 自動化・DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 4
  5. 5. DevOpsとは?
  6. 6. DevOpsとは? • 開発と運用が密に連携して協力しあう開発 手法 – DevOpsを支援する技術やツールを積極的に 利用 – 開発は新しい機能を安心してリリースできる – 運用は新しい機能を安心して受け入れられる ↓ 変化に対して前向きに進みやすくする 6
  7. 7. DevOpsを支える要素・技術 • 自動化 – テストの自動化 – インフラ構築の自動化 • 効率化 – 継続的インテグレーション(CI) – 継続的デリバリー(CD) • チーム開発(共有化?) – 運用モデルに基づくバージョン管理 – チケット駆動開発によるタスクの明確化 7
  8. 8. 継続的インテグレーション(CI) • ビルドやテストを短期間で繰り返し行い開発 効率を上げる手法 – 定期的に実行(デイリービルド) – バグを早期に発見(短期間で繰り返しテスト) – 他のツールと連動(進捗管理等) • 代表的なツール – Jenkins – Atlassian Bamboo – CircleCI (SaaS) – Travis CI (SaaS) 8
  9. 9. 継続的デリバリー(CD) • CIの仕組みをインフラ構築まで拡張 – テストした成果物を自動デプロイメント • インフラ構築自動化と組み合わせることで 短時間で構築可能 – テスト環境と本番環境を同等の構成で構築 – インフラを含めた結合テストを自動化 9
  10. 10. Gitを利用した開発モデル 10
  11. 11. Gitを利用したバージョン管理 • ソースコード等の共有 – 変更履歴を記録、追跡 – 履歴の用途毎に分岐して管理(ブランチ) – 切り戻しが容易 • プルリクエスト(マージリクエスト)機能によ りレビューを可視化 • 他のツールとの連携 – Jenkins – Redmine 11
  12. 12. Gitを利用したバージョン管理 A successful Git branching model http://nvie.com/posts/a-successful-git-branching-model/ – リリース用と開発用の2つのメインブランチを 用意 – 機能追加、バグフィックス等Issue登録を行う毎 にメインブランチから切り出す – 問題が起きても本番用ブランチや他の人の開 発には影響しない – GitLabではマージリクエスト機能によりレ ビューを可視化 12
  13. 13. git-flowの例 master hotfix-001 release-ver1 develop feature-001 feature-002 Ver.0.1 Ver.0.2 Ver.1.0 機能追加 Ver.1リリース準備 機能追加 13 緊急バグ修正 バグ修正
  14. 14. バージョン管理とCI/CD • インフラ環境を自動構築しテスト – クラウドやコンテナを活用 – 本番同様のインフラ環境でテストが可能 • 本番環境へのリリース時も毎回新規構築 – リリース直後に問題が発生した場合でも、旧 環境へすぐに切り戻せる 14
  15. 15. CI/CD/DevOpsの範囲 コード修正 静的テスト ビルド 単体テスト / 統合テスト インフラ構築 / デプロイメント 本番 運用 継続的インテグレーション(CI) 継続的デリバリー(CD) DevOps
  16. 16. GitLabを使って試してみよう 16
  17. 17. デモ環境について 『GitLab実践ガイド』を参考に • CentOS 7.4にGitLab Community Editionを インストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当 – Omnibusインストールで必要なものがまとまっ て入ります 17
  18. 18. GitLabインストール時の注意点 • 「Installation using the Omnibus packages」を参考に 環境を構築 – 普通にインストールページに行くとEEになっている – https://about.gitlab.com/installation/#centos-7 • CEをインストールしたい場合は、上記ページの一 番下の「CE or EE」をクリックし、さらに一番下の 「Install GitLab Community Edition」をクリック – https://about.gitlab.com/installation/#centos- 7?version=ce • ホスト名の決定方法がやや難解です 18
  19. 19. CentOS 7.4へのインストール 1. sudo yum install -y curl policycoreutils-python openssh-server 2. sudo systemctl enable sshd 3. sudo systemctl start sshd 4. sudo firewall-cmd --permanent --add-service=http 5. sudo systemctl reload firewalld 6. curl https://packages.gitlab.com/install/repositories/gitl ab/gitlab-ce/script.rpm.sh | sudo bash 7. yum install -y gitlab-ce 19
  20. 20. ホスト名の指定と構成変更の適用 • 以下の条件の場合、インストールの最後で自 動的に構成変更が適当される – ホスト名が正しく設定されている – 逆引きDNSでホスト名を返す • 【重要】ホスト名を指定して、構成変更の適用 を行う必要がある – /etc/gitlab/gitlab.rbが設定ファイル • external_url ‘http://gitlab.example.com’ – 設定後再構成を実行 • sudo gitlab-ctl reconfigure 20
  21. 21. GitLab関連コマンド • GitLabの起動状態確認 – gitlab-ctl status • GitLabの起動/停止/再起動 – gitlab-ctl start/stop/restart – 後ろに個別のサービス名を付けることも可能 21
  22. 22. GitLabにプロジェクトを作成する 22
  23. 23. GitLabの管理単位 • ユーザー – 各開発者のアカウント • グループ – ユーザーをまとめた管理単位 • プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 23
  24. 24. GitLabで初期設定作業 1. http://gitlab.example.comにアクセス 2. ユーザーrootのパスワードを設定 3. ユーザーrootでログイン 4. 新しいユーザーを作成 5. 指定したメールアドレスにメールが届く – http://gitlab.example.comへのリンクが埋め込まれ ている() 6. 新規ユーザーのパスワード設定 7. 新規ユーザーでログイン 24
  25. 25. ユーザーでプロジェクト作成 ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. リポジトリのURLを確認 3. クライアントにリポジトリをクローン – SourceTree:URLを取得し、ユーザー認証 – gitコマンド: git clone http://gitlab.example.com/tmiyahar/test.git • ユーザー認証が必要 25
  26. 26. Gitのリポジトリ種別 • ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される • クローンが一番分かりやすい – 他の開発者には影響しない • リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 26
  27. 27. ローカルリポジトリの確認 • クローンしたリポジトリを確認 – $ cd ~/test – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 27
  28. 28. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $ touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push --set-upstream origin master • masterブランチのアップストリームをリモートリポジトリの master(remotes/origin/master)に設定 28
  29. 29. ステージングとコミットの関係 29 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git checkout $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している
  30. 30. リモートリポジトリとの関係 30 ローカル リポジトリ リモート リポジトリ コミット1をプッシュ コミット2をプッシュ コミット3を未プッシュ プル 別の開発者 がプッシュ
  31. 31. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmasterだけ 2. ブランチの作成 – $ git branch develop 3. ブランチの切り替え(チェックアウト) – $ git checkout develop – $ git checkout –b develop で作成&移動も 4. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 31
  32. 32. ブランチの流れ 32 master develop $ git branch $ git merge
  33. 33. developブランチで作業 1. developブランチのREADME.mdを修正 2. 修正をステージングとコミット – $ git add README.md – $ git commit – $ git commit -a でまとめて実行も可能 3. masterブランチのREADME.mdを確認 – $ git checkout master – $ cat README.md – developブランチでの修正が影響していない事を 確認 33
  34. 34. developブランチをマージする 1. developブランチをmasterにマージする – $ git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される • マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ(プ ル)リクエスト」を作成する 34
  35. 35. 超入門の次のステップは? • 修正の重複(コンフリクト)の解消 – git push時に既にリモートが更新されている – git pullするとコンフリクト発生 – 適切に修正し、再度コミット&プッシュ 35 developブランチで修正 <<<<<<< HEAD ローカルのmasterブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
  36. 36. ブランチ戦略を考える よくある質問 • Q. 「どのブランチ戦略がいいんですか?」 • A. 「ケースバイケース」 • 考慮すべき事(順不同) – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 36
  37. 37. この先に考えたい事 • テスト駆動やチケット駆動との連携 • テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 • チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 37
  38. 38. ニフクラとGitLab • メモリが4GBは必要(100ユーザー見込み) – 月額まぁまぁの金額 – ただし、GitLabはかなり高機能なのでGitリポ ジトリとしてだけ使うのはもったいない • オンプレ側に置いてVPN接続? • もう少し軽いものを使う? – BitBucket? • 外部サービスとの連携 – GitHub.comとかGitLab.comとか 38
  39. 39. ニフクラとDevOps • API連携を試したい! • コンテナを使いたい! • PaaSサービスを充実して欲しい! • エンジニア同士の情報共有を図りたい! 39 今後もミートアップでアレこれ話しましょう
  40. 40. ありがとうございました 40

×