今さら闻けない人のための骋颈迟超入门 GitLab 14対応版
Download as PPTX, PDF2 likes662 views
今さら闻けない人のための骋颈迟超入门 GitLab 14対応版
![リポジトリ操作実行例
$ touch README.md
$ git add README.md
$ git commit
[main (root-commit) 77eb748] add README.md
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README.md
$ git push -u origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To http://gitlab.example.com/tmiyahar/test.git
* [new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
33](https://image.slidesharecdn.com/210828git-210829063048/85/Git-GitLab-14-33-320.jpg)
![3. git push 失敗
$ git push
To http://gitlab.example.com/tmiyahar/test.git
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'http://gitlab.example.com/tmiyahar/test.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
42](https://image.slidesharecdn.com/210828git-210829063048/85/Git-GitLab-14-42-320.jpg)
![5. 6. コンフリクト修正と再push
$ vi README.md
$ git commit -a
[main 2705f27] Merge branch 'main' of
http://gitlab.example.com/tmiyahar/test
$ git push
Enumerating objects: 10, done.
Counting objects: 100% (10/10), done.
Delta compression using up to 16 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), 537 bytes | 537.00 KiB/s, done.
Total 6 (delta 0), reused 0 (delta 0), pack-reused 0
To http://gitlab.example.com/tmiyahar/test.git
9cb63b7..2705f27 main -> main
44](https://image.slidesharecdn.com/210828git-210829063048/85/Git-GitLab-14-44-320.jpg)
![スマホゲームのチート手法とその対策 [DeNA TechCon 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/techcon2019funakubo-190218065153-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to 今さら闻けない人のための骋颈迟超入门 GitLab 14対応版 (20)
More from VirtualTech Japan Inc./Begi.net Inc. (20)
今さら闻けない人のための骋颈迟超入门 GitLab 14対応版
- 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. 日本仮想化技術株式会社 概要 ? 社名：日本仮想化技術株式会社 – 英語名：VirtualTech Japan Inc. – 略称：日本仮想化技術／VTJ ? 設立：2006年12月 ? 資本金：3,000万円 ? 売上高：26,000万円（2021年7月期） ? 本社：東京都渋谷区渋谷1-8-1 ? 取締役：宮原 徹（代表取締役社長兼CEO） ? 伊藤 宏通（取締役CTO） ? スタッフ：10名（うち、8名が仮想化技術専門エンジニアです） ? URL：http://VirtualTech.jp/ ? 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築?運用サポート – OpenStackの導入支援?新規機能開発?運用サポート – 自動化?DevOps支援 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 3
- 5. 日本仮想化技術株式会社は ? 仮想化技術のエキスパート集団 ? 進取の精神 ? 豊富な検証機材で新技術を追求 ? 自由な雰囲気の職場 5
- 6. エンジニアの幸せとは？ ? 給料が沢山もらえる ? 仕事が面白い ? 仕事場の環境が良い ? 新しい技術に触れられる ? 残業が少ない ? 健康的な生活がおくれる 6 各人によって価値観はそれぞれ
- 7. 会社としてできること ? 新しい技術に積極的に取り組む – そもそも「仮想化技術」が新しい技術だった ? できるだけ給与を多く – 年間昇給率5%目標 – 決算賞与による利益分配を厚く ? 仕事のしやすい環境を提供 – 可能な限り最高の環境を提供 – 制約はできるだけ少なく 7
- 8. 経営方針 ? 大きい会社が手を出せない新しいことや違 うやり方にどんどん挑戦する ? 新しくて面白いことをやるために – 仕事そこそこ（遊ぶための時間の確保） – 売上そこそこ（売上至上主義にならない） – 利益トントン（会社が潰れない程度でOK） 8
- 9. 新しい技術への取り組み ? 通信キャリアと共同R&Dが事業の主な柱 ? 次期インフラのための調査研究 – コンテナ – GPU – 5G ? 次期サービスのための基礎技術 – VR/AR/xR – 映像配信 9 このあたりは当然のように 業務として取り組んでいます このあたりは趣味だったが 業務として扱うようになってきた
- 10. できるだけ給与を多く 従来の報酬方針から転換中 ? 従来：月々の給与をほどほどに抑えつつ、 最終的な決算の賞与を手厚く ? 課題：会社としての売上利益が増えてきた ため、給与と決算賞与がアンバランスに?? ? 今後：月々の給与を厚くしつつ、決算賞与 もしっかり支給 10
- 11. 仕事のしやすい環境 2020年3月から完全在宅勤務に移行 ? 在宅勤務手当て2万円支給 – 通勤費＋オフィス福利厚生費相当 ? 自宅環境整備費用無制限 – アーロンチェア支給（デカくて置けない、と断られ ることも??） – 液晶モニター支給（27インチ以上?4K） – M1 Mac支給（追加配備開始） ? その他、業務に必要なものはもちろん、今後 面白そうなものも購入無制限（に近い） 11
- 12. 今募集している仕事 ? R&D系の仕事 – サーバー、ネットワーク等のインフラ構築?運用経 験者 – K8sを活用したコンテナインフラ – GPUなどを活用したAIインフラ – SDNを活用したネットワークインフラ ? DevOpsの仕事 – Opsチームとして開発サポート＆本番運用 – アジャイル開発チームの立ち上げ – そろそろDevOps事業部が立ち上がりそうです！ 12
- 14. 本日のアジェンダ ? Gitを利用した開発モデル ? GitLabを使って試してみよう ? GitLabにプロジェクトを作成する ? DevOpSaaSに向けて ? CI/CDを支える中心的な技術であるコード管 理の代表的なGitの使用方法を講師なりに勉 強して仕組みを理解できるように解説します 14
- 15. Gitを利用した開発モデル 15
- 16. Gitを利用したバージョン管理 ? ソースコード等の共有 – 変更履歴を記録、追跡（バージョン管理） – 履歴の用途毎に分岐して管理（ブランチ） – 切り戻しが容易 ? プルリクエスト（マージリクエスト）機能によ りレビューを可視化 ? 他のツールとの連携 – Jenkins – Redmine 16
- 19. デモ環境について ? Ubuntu 20.04LTSにGitLab 14.1 Enterprise Editionをインストール – Enterprise Editionでもライセンスを有効にしな ければCommunity Edition相当（GitLab Core） – Omnibusインストールで必要なものがまとまっ て入ります 19
- 20. GitLabをインストールする ? GitLabのWebページ 「Official Linux package (recommended installation)」を参考に環境を構築 – https://about.gitlab.com/install/#ubuntu – Kubernetesやクラウド上へのインストールも可能 1. GitLabのWebページ（https://about.gitlab.com/）の Productメニューから「Install GitLab」を選択 2. インストールしたいOS?環境を選択 3. 手順に従ってインストール 20
- 21. GitLab 14インストールの注意点 ? Let's EncryptによるTLS化がデフォルトに – ドキュメントでのインストール時の EXTERNAL_URLの指定が"https://○○"に →オンプレ、ローカルIPアドレスだとLet's Encrypt のTLS証明書生成がコケてインストール失敗 – EXTERNAL_URLの指定を"http://○○"に ? DNSの逆引き名前解決の設定が必要 – /etc/hostsではダメ – インストールスクリプト（Chef利用）がコケるので、 gitlab-ctl reconfigureの実行が必要 21
- 22. Ubuntu 20.04LTSへのインストール 1. sudo apt-get update 2. sudo apt-get install -y curl openssh-server ca-certificates tzdata perl 3. sudo apt-get install -y postfix – 用途が求められるので適当に 4. curl https://packages.gitlab.com/install/repositories/ gitlab/gitlab-ee/script.deb.sh | sudo bash 5. sudo EXTERNAL_URL="http://gitlab.example.com" apt-get install gitlab-ee – 注）逆引き名前解決でコケるとconfigに失敗します 6. sudo gitlab-ctl reconfigure 22 ←必ず実行
- 24. GitLabの管理単位 ファイルサーバーと大体同じと思えばOK ? ユーザー – 各開発者のアカウント ? グループ – ユーザーをまとめた管理単位 ? プロジェクト – ソースコードのリポジトリを含めた開発プロ ジェクトに必要なもの一式 – ユーザー、あるいはグループに紐付けられる 24
- 25. GitLabで初期設定作業 1. rootパスワードを確認 – /etc/gitlab/initial_root_passwordに記載 2. http://gitlab.example.comにアクセス 3. ユーザーrootでログイン 4. ユーザーrootのパスワードを変更 – 右上のアイコン→Edit Profile→Password 5. 新しいユーザーを作成 – Menu→Admin→Users→New User 6. 新規ユーザーのパスワード設定 – ユーザー情報ページ→Edit 7. 新規ユーザーでログイン 25
- 26. プロジェクト作成とクローン ユーザーtmiyaharを作成しています 1. 新規プロジェクトtestを作成 2. クライアントにリポジトリをクローン – git clone http://gitlab.example.com/tmiyahar/test.git ? ユーザー認証が必要 26 $ git clone http://gitlab.example.com/tmiyahar/test.git Cloning into 'test'... Username for 'http://gitlab.example.com': tmiyahar Password for 'http://tmiyahar@gitlab.example.com': ※パスワード warning: You appear to have cloned an empty repository.
- 28. Gitのリポジトリ種別 ? ローカルリポジトリ – 開発作業用クライアントに作成される – リモートリポジトリをクローンすると作成される ? クローンが一番分かりやすい – 作業は他の開発者には影響しない ? リモートリポジトリ – GitLab上に作成される – 各開発者で共有される 28
- 29. ローカルリポジトリの確認 ? クローンしたリポジトリを確認 – $ cd ~/test – $ git switch -c main – $ ls -a – 現時点では空っぽです – .gitディレクトリが作られており、リポジトリの各 種情報が格納されている 29
- 30. ステージングとコミットの関係 30 作業用 ディレクトリ ステージング 領域 ローカル リポジトリ $ git switch $ git add $ git commit リポジトリは ブランチ毎の ファイルセットを 保持している main develop
- 32. リポジトリにファイルを追加 1. 作業ディレクトリにファイルを追加 – $ touch README.md 2. ファイルをステージング – $ git add README.md 3. ステージングしたファイルをコミット – $ git commit 4. コミットしたファイルをリモートにプッシュ – 同時にローカルリポジトリのアップストリーム設定 – $ git push -u origin main ? mainブランチのアップストリームをリモートリポジトリの main（remotes/origin/main）に設定 32
- 33. リポジトリ操作実行例 $ touch README.md $ git add README.md $ git commit [main (root-commit) 77eb748] add README.md 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 README.md $ git push -u origin main Enumerating objects: 3, done. Counting objects: 100% (3/3), done. Writing objects: 100% (3/3), 218 bytes | 218.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 To http://gitlab.example.com/tmiyahar/test.git * [new branch] main -> main Branch 'main' set up to track remote branch 'main' from 'origin'. 33
- 34. ブランチの流れ 34 main develop ① $ git switch -c develop ③ $ git merge develop ②コミットを繰り返す
- 35. ブランチを作成する 1. ブランチの確認 – $ git branch – 現時点ではローカルのmainだけ 2. ブランチの新規作成と切り替え – $ git switch -c develop – 従来のgit checkout -b相当 3. ブランチの確認 – $ git branch – 作業しているブランチがdevelopに変更されている 35
- 36. ブランチ作成実行例 $ git branch * main $ git switch -c develop Switched to a new branch 'develop’ $ git branch * develop main 36
- 37. developブランチで作業 1. developブランチのREADME.mdを修正 – エディタで何か書きます 2. 修正をステージングとコミット – $ git add README.md – $ git commit – $ git commit -a でまとめて実行も可能 3. mainブランチのREADME.mdを確認 – $ git switch main – $ cat README.md – developブランチでの修正が影響していない事を 確認 37
- 38. developブランチをマージする 1. developブランチにコミットされた修正差分 をmainブランチにマージする – $ git merge develop 2. README.mdを確認 – developブランチで行った修正が反映される ? マージは取り込む側のブランチで行う – だから、取り込んで欲しいときは「マージ（プ ル）リクエスト」を作成する 38
- 40. 修正の重複（コンフリクト）の解消 ? git push時に既にリモートが更新されているとプッ シュに失敗する ? git pullするとコンフリクト発生が通知され、対象と なるファイルが以下のようになる ? 適切に修正し、再度コミット＆プッシュ 40 developブランチで修正 <<<<<<< HEAD ローカルのmainブランチで修正 ======= Webブラウザで修正 >>>>>>> fcfafd335fd5d6a4bb8938c1c2dcbe17788debf5
- 41. コンフリクト解消手順 1. WebブラウザでREADME.mdを確認 – この時点では空っぽです 2. Editボタンを押して何か書く – 他のユーザーがpushしたのと同義 3. $ git push – Webブラウザ側での変更が取り込まれておらず失敗 4. $ git pull – コンフリクトが発生し、自動マージに失敗 5. README.mdを編集してコンフリクトを解消 6. 再度、コミット＆プッシュします – 今度は成功します 41
- 42. 3. git push 失敗 $ git push To http://gitlab.example.com/tmiyahar/test.git ! [rejected] main -> main (fetch first) error: failed to push some refs to 'http://gitlab.example.com/tmiyahar/test.git' hint: Updates were rejected because the remote contains work that you do hint: not have locally. This is usually caused by another repository pushing hint: to the same ref. You may want to first integrate the remote changes hint: (e.g., 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 42
- 43. 4. git pullするとコンフリクト発生 $ git pull （rebase関係の設定をしろとhintが出るがとりあえず今回は無視） remote: Enumerating objects: 5, done. remote: Counting objects: 100% (5/5), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (3/3), 232 bytes | 232.00 KiB/s, done. From http://gitlab.example.com/tmiyahar/test 77eb748..9cb63b7 main -> origin/main Auto-merging README.md CONFLICT (content): Merge conflict in README.md Automatic merge failed; fix conflicts and then commit the result. 43
- 44. 5. 6. コンフリクト修正と再push $ vi README.md $ git commit -a [main 2705f27] Merge branch 'main' of http://gitlab.example.com/tmiyahar/test $ git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 16 threads Compressing objects: 100% (2/2), done. Writing objects: 100% (6/6), 537 bytes | 537.00 KiB/s, done. Total 6 (delta 0), reused 0 (delta 0), pack-reused 0 To http://gitlab.example.com/tmiyahar/test.git 9cb63b7..2705f27 main -> main 44
- 45. ブランチ戦略を考える よくある質問 ? Q. 「どのブランチ戦略がいいんですか？」 ? A. 「ケースバイケース」 ? 考慮すべき事（順不同） – 開発者の人数や規模 – コミットやマージの頻度や粒度 – テストの頻度や方法 – リリースの頻度や方法 45
- 46. この先に考えたい事 ? テスト駆動やチケット駆動との連携 ? テストの自動化 – コードコミット→テスト→マージリクエストのサ イクルの自動化 – 粒度が小さいとマージ処理する人が大変 ? チケットの自動化 – テスト失敗時に自動的にチケット発行 – テスト成功時に自動的にチケットクローズ 46
- 47. DevOpSaaSに向けて 47
- 48. DevOpsの想定される進め方 1. ToBeモデルの構築 2. 現時点での課題の抽出 3. 優先順位の策定 4. PoC環境の構築と運用 5. PoC環境からのフィードバックと改善 6. 小規模社内展開 48 自社だけではスピード感のある DevOps推進は困難
- 49. DevOpsを始める時に悩むこと ? どのインフラを使うの？ ? どのリポジトリを使うの？ ? 情報共有方法は？ 49
- 50. DevOpSaaSが解決する課題 標準リファレンスモデル提供によるDevOpsの加速 ? 各種ツールの組み合わせテスト済みパッケージの提供 – 標準機能はあらかじめ設定済み ? 各種ツールのバージョンアップ追従 – 既存開発?運用環境からの移行支援 ? 独自機能の提供 – 可視化ツール、既存ツールのカスタマイズなど ? 開発運用担当者の教育?サポート – 標準ドキュメント、教育コースの提供 ? サンプルの提供 – 自動化?テストスクリプトのサンプル
- 51. 提供される主な機能 ? チケット管理 ? ソースコード管理 ? テスト自動化 ? デプロイ自動化 ? プロジェクトマネジメント ? コミュニケーション 51
- 52. サポートされる環境 ? 開発：GitHub/GitLab/Jenkins/Redmine – CircleCI ? 構成自動化：Ansible – CloudFormation ? インフラ：Kubernetes – AWS EKS ? 運用監視：Prometheus – DataDog ? テスト自動化：Serverspec/Selenium 52 ※実案件で実績あり
- 53. 改めて大募集 ? 一緒にDevOpsにチャレンジする企業 – 一緒にカイゼンしていきませんか？ ? 一緒にDevOpsにチャレンジするエンジニア – 一緒に成長していきませんか？ – 沢山の開発者を支えるお仕事です – マジで人手が足りてません – このままだと掛け声倒れになりかねない 53
- 54. ありがとうございました 54