Enviar pesquisa
Carregar
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
•
102 gostaram
•
50,159 visualizações
CROOZ, inc.
Seguir
Tecnologia
Denunciar
Compartilhar
Denunciar
Compartilhar
1 de 54
Baixar agora
Baixar para ler offline
Recomendados
目grep入門 +解説
目grep入門 +解説
murachue
[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門
Google Cloud Platform - Japan
AnsibleによるInfrastructure as code入門
AnsibleによるInfrastructure as code入門
kk_Ataka
Samba4を「ふつうに」使おう!
Samba4を「ふつうに」使おう!
基信 高橋
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
入門!Jenkins
入門!Jenkins
Shuntaro Saiba
自宅ラック勉強会 2.2 夏のZabbix特別教室 ~構築編~
自宅ラック勉強会 2.2 夏のZabbix特別教室 ~構築編~
真乙 九龍
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Recomendados
目grep入門 +解説
目grep入門 +解説
murachue
[GKE & Spanner 勉強会] GKE 入門
[GKE & Spanner 勉強会] GKE 入門
Google Cloud Platform - Japan
AnsibleによるInfrastructure as code入門
AnsibleによるInfrastructure as code入門
kk_Ataka
Samba4を「ふつうに」使おう!
Samba4を「ふつうに」使おう!
基信 高橋
分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
入門!Jenkins
入門!Jenkins
Shuntaro Saiba
自宅ラック勉強会 2.2 夏のZabbix特別教室 ~構築編~
自宅ラック勉強会 2.2 夏のZabbix特別教室 ~構築編~
真乙 九龍
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
Kubernetesでの性能解析 ~なんとなく遅いからの脱却~(Kubernetes Meetup Tokyo #33 発表資料)
NTT DATA Technology & Innovation
Spring 歴約1年初心者の Test 奮闘記
Spring 歴約1年初心者の Test 奮闘記
chishizu naito
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Ansible specでテストをする話
Ansible specでテストをする話
KeijiUehata1
GitHubの機能を活用したGitHub Flowによる開発の進め方
GitHubの機能を活用したGitHub Flowによる開発の進め方
Takeshi Mikami
入門Ansible
入門Ansible
Taku SHIMIZU
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
swamp Sawa
インフラCICDの勘所
インフラCICDの勘所
Toru Makabe
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
Kubernetes環境で実現するWebアプリケーションセキュリティ
Kubernetes環境で実現するWebアプリケーションセキュリティ
NGINX, Inc.
Ansibleで始めるインフラ構築自動化
Ansibleで始めるインフラ構築自動化
dcubeio
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWS
Amazon Web Services Japan
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
Google Cloud Platform - Japan
GNU AGPLv3について(On GNU AGPLv3)
GNU AGPLv3について(On GNU AGPLv3)
真行 八田
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
Kohei Tokunaga
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
Google Cloud Platform - Japan
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
少人数チームにおけるプロジェクト管理のベストプラクティス
少人数チームにおけるプロジェクト管理のベストプラクティス
Cake YOSHIDA
Redmine + gitlab: merge base development
Redmine + gitlab: merge base development
smdkk
Mais conteúdo relacionado
Mais procurados
Spring 歴約1年初心者の Test 奮闘記
Spring 歴約1年初心者の Test 奮闘記
chishizu naito
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
Ansible specでテストをする話
Ansible specでテストをする話
KeijiUehata1
GitHubの機能を活用したGitHub Flowによる開発の進め方
GitHubの機能を活用したGitHub Flowによる開発の進め方
Takeshi Mikami
入門Ansible
入門Ansible
Taku SHIMIZU
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
swamp Sawa
インフラCICDの勘所
インフラCICDの勘所
Toru Makabe
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Shohei Koyama
Kubernetes環境で実現するWebアプリケーションセキュリティ
Kubernetes環境で実現するWebアプリケーションセキュリティ
NGINX, Inc.
Ansibleで始めるインフラ構築自動化
Ansibleで始めるインフラ構築自動化
dcubeio
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWS
Amazon Web Services Japan
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
Kentaro Yoshida
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
Google Cloud Platform - Japan
GNU AGPLv3について(On GNU AGPLv3)
GNU AGPLv3について(On GNU AGPLv3)
真行 八田
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
Kohei Tokunaga
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
Google Cloud Platform - Japan
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
AdvancedTechNight
Mais procurados
(20)
Spring 歴約1年初心者の Test 奮闘記
Spring 歴約1年初心者の Test 奮闘記
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Ansible specでテストをする話
Ansible specでテストをする話
GitHubの機能を活用したGitHub Flowによる開発の進め方
GitHubの機能を活用したGitHub Flowによる開発の進め方
入門Ansible
入門Ansible
ゼロ幅スペースという悪夢
ゼロ幅スペースという悪夢
インフラCICDの勘所
インフラCICDの勘所
インフラエンジニアの綺麗で優しい手順書の書き方
インフラエンジニアの綺麗で優しい手順書の書き方
Kubernetes環境で実現するWebアプリケーションセキュリティ
Kubernetes環境で実現するWebアプリケーションセキュリティ
Ansibleで始めるインフラ構築自動化
Ansibleで始めるインフラ構築自動化
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWS
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
Fluentdのお勧めシステム構成パターン
Fluentdのお勧めシステム構成パターン
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
[Cloud OnAir] Google Cloud で実現するバックアップ ディザスタリカバリのベストプラクティス 2019年4月25日 放送
GNU AGPLv3について(On GNU AGPLv3)
GNU AGPLv3について(On GNU AGPLv3)
OCIランタイムの筆頭「runc」を俯瞰する
OCIランタイムの筆頭「runc」を俯瞰する
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
[External] 2021.12.15 コンテナ移行の前に知っておきたいこと @ gcpug 湘南
単なるキャッシュじゃないよ!?infinispanの紹介
単なるキャッシュじゃないよ!?infinispanの紹介
Destaque
少人数チームにおけるプロジェクト管理のベストプラクティス
少人数チームにおけるプロジェクト管理のベストプラクティス
Cake YOSHIDA
Redmine + gitlab: merge base development
Redmine + gitlab: merge base development
smdkk
個人のタスク管理からチケット駆動開発の特徴を考える
個人のタスク管理からチケット駆動開発の特徴を考える
Makoto SAKAI
GitLab Meetup Tokyo #1 LT:「わりと大きい会社でGitLabをホスティングしてみた話」
GitLab Meetup Tokyo #1 LT:「わりと大きい会社でGitLabをホスティングしてみた話」
Taisuke Inoue
GitとCIとかチャットとかをオンプレで運用する話
GitとCIとかチャットとかをオンプレで運用する話
mdome
GitLab/GitLab.com勉強会 第2回
GitLab/GitLab.com勉強会 第2回
NaohiroHamada
Rancher と GitLab を使う3つの理由
Rancher と GitLab を使う3つの理由
Tetsurou Yano
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
Shuji Yamada
kintoneチームのKAIZEN文化
kintoneチームのKAIZEN文化
Ryo Mitoma
インフラ構築とテストについて(ITインフラ業務自動化現状確認会)
インフラ構築とテストについて(ITインフラ業務自動化現状確認会)
Yosuke Hiraishi
Destaque
(10)
少人数チームにおけるプロジェクト管理のベストプラクティス
少人数チームにおけるプロジェクト管理のベストプラクティス
Redmine + gitlab: merge base development
Redmine + gitlab: merge base development
個人のタスク管理からチケット駆動開発の特徴を考える
個人のタスク管理からチケット駆動開発の特徴を考える
GitLab Meetup Tokyo #1 LT:「わりと大きい会社でGitLabをホスティングしてみた話」
GitLab Meetup Tokyo #1 LT:「わりと大きい会社でGitLabをホスティングしてみた話」
GitとCIとかチャットとかをオンプレで運用する話
GitとCIとかチャットとかをオンプレで運用する話
GitLab/GitLab.com勉強会 第2回
GitLab/GitLab.com勉強会 第2回
Rancher と GitLab を使う3つの理由
Rancher と GitLab を使う3つの理由
会社にGitHub Enterpriseを導入してみた話
会社にGitHub Enterpriseを導入してみた話
kintoneチームのKAIZEN文化
kintoneチームのKAIZEN文化
インフラ構築とテストについて(ITインフラ業務自動化現状確認会)
インフラ構築とテストについて(ITインフラ業務自動化現状確認会)
Semelhante a GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
Gitと出会って人生変わった テックヒルズ2013-03-22
Gitと出会って人生変わった テックヒルズ2013-03-22
Shota Umeda
Dangerでpull requestレビューの指摘事項を減らす
Dangerでpull requestレビューの指摘事項を減らす
Shunsuke Maeda
Node-REDのロードマップや見どころ
Node-REDのロードマップや見どころ
BMXUG
Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介
Makoto Haruyama
Git/GitHub
Git/GitHub
Nariaki Tateiwa
XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用
賢次 海老原
怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用
CROOZ, inc.
Git & GitHub & kintone でウルトラハッピー!
Git & GitHub & kintone でウルトラハッピー!
ymmt
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
Issei Hiraoka
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
YusukeKuramata
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
DIVE INTO CODE Corp.
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
Toru Yamaguchi
VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011
Hiro Yoshioka
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
DIVE INTO CODE Corp.
Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)
Kohsuke Kawaguchi
[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005
Microsoft Tech Summit 2017
iOSにおけるコードレビューを一歩先へ進める
iOSにおけるコードレビューを一歩先へ進める
Shunsuke Maeda
Gitを使った運用方法
Gitを使った運用方法
Hiroki Nigorinuma
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
Yukihiko SAWANOBORI
dstn交流会_data_spider 3.0最新情報とデモ
dstn交流会_data_spider 3.0最新情報とデモ
dstn
Semelhante a GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
(20)
Gitと出会って人生変わった テックヒルズ2013-03-22
Gitと出会って人生変わった テックヒルズ2013-03-22
Dangerでpull requestレビューの指摘事項を減らす
Dangerでpull requestレビューの指摘事項を減らす
Node-REDのロードマップや見どころ
Node-REDのロードマップや見どころ
Rails on GKEで運用するWebアプリケーションの紹介
Rails on GKEで運用するWebアプリケーションの紹介
Git/GitHub
Git/GitHub
XPages開発におけるGit/GitHubの利用
XPages開発におけるGit/GitHubの利用
怖くないブランチ開発外部公開用
怖くないブランチ開発外部公開用
Git & GitHub & kintone でウルトラハッピー!
Git & GitHub & kintone でウルトラハッピー!
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
2021/03/19 パブリッククラウドを活かす運用プロセス自動化
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
ゼロからのプログラミングRails講座 Codeanywhere版
ゼロからのプログラミングRails講座 Codeanywhere版
技術選択とアーキテクトの役割
技術選択とアーキテクトの役割
VCS - Version Control System at Security and Programming camp 2011
VCS - Version Control System at Security and Programming camp 2011
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
アイデアを形にする ③3時間でアプリ公開!ゼロからのプログラミング講座
Jenkins+Gitによる検証済みマージ(30分版)
Jenkins+Gitによる検証済みマージ(30分版)
[Japan Tech summit 2017] DEP 005
[Japan Tech summit 2017] DEP 005
iOSにおけるコードレビューを一歩先へ進める
iOSにおけるコードレビューを一歩先へ進める
Gitを使った運用方法
Gitを使った運用方法
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
密着! nibohsiデプロイ 13:00-13:05 - railsアプリのデプロイ事例 -
dstn交流会_data_spider 3.0最新情報とデモ
dstn交流会_data_spider 3.0最新情報とデモ
Mais de CROOZ, inc.
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ, inc.
【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料
CROOZ, inc.
【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料
CROOZ, inc.
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
CROOZ, inc.
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
CROOZ, inc.
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
CROOZ, inc.
Mongo db勉強会の補足
Mongo db勉強会の補足
CROOZ, inc.
Mongo dbを知ろう
Mongo dbを知ろう
CROOZ, inc.
リソースディレクトリの管理
リソースディレクトリの管理
CROOZ, inc.
楽しいGit外部公開用
楽しいGit外部公開用
CROOZ, inc.
Git extensions ws外部公開用
Git extensions ws外部公開用
CROOZ, inc.
Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用
CROOZ, inc.
MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用
CROOZ, inc.
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02
CROOZ, inc.
MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09
CROOZ, inc.
Mais de CROOZ, inc.
(15)
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
CROOZ SHOPLIST株式会社 エンジニア向け会社説明資料
【CROOZ】新卒会社説明資料
【CROOZ】新卒会社説明資料
【CROOZ】新卒採用_会社説明資料
【CROOZ】新卒採用_会社説明資料
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
モバイルゲームの全世界オンライン対戦を実現する方法を考察する
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
全世界135か国に配信したレーシングゲーム『ACR DRIFT』の制作秘話と技術基盤の構築について
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
第7回テックヒルズ『Game Engines!!~どのゲームエンジンを選ぶ?~』資料
Mongo db勉強会の補足
Mongo db勉強会の補足
Mongo dbを知ろう
Mongo dbを知ろう
リソースディレクトリの管理
リソースディレクトリの管理
楽しいGit外部公開用
楽しいGit外部公開用
Git extensions ws外部公開用
Git extensions ws外部公開用
Piwikを用いたアクセス解析外部公開用
Piwikを用いたアクセス解析外部公開用
MySQL Index勉強会外部公開用
MySQL Index勉強会外部公開用
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 インデックス編.2013 08-02
MySQL勉強会 リプリケーション編.2013 08-09
MySQL勉強会 リプリケーション編.2013 08-09
Último
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
Hiroki Ichikura
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
iPride Co., Ltd.
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
Toru Tamaki
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
Toru Tamaki
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Yuma Ohgami
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
Ryo Sasaki
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
Toru Tamaki
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
sugiuralab
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
taisei2219
Último
(9)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
【早稲田AI研究会 講義資料】3DスキャンとTextTo3Dのツールを知ろう!(Vol.1)
SOPを理解する 2024/04/19 の勉強会で発表されたものです
SOPを理解する 2024/04/19 の勉強会で発表されたものです
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Semantic segmentation using Vision Transformers: A survey
論文紹介:Automated Classification of Model Errors on ImageNet
論文紹介:Automated Classification of Model Errors on ImageNet
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
Open Source UN-Conference 2024 Kawagoe - 独自OS「DaisyOS GB」の紹介
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
[DevOpsDays Tokyo 2024] 〜デジタルとアナログのはざまに〜 スマートビルディング爆速開発を支える 自動化テスト戦略
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
論文紹介:Content-Aware Token Sharing for Efficient Semantic Segmentation With Vis...
スマートフォンを用いた新生児あやし動作の教示システム
スマートフォンを用いた新生児あやし動作の教示システム
TSAL operation mechanism and circuit diagram.pdf
TSAL operation mechanism and circuit diagram.pdf
GitLab & web hooks & git-flowで実現する企業向けgit環境の構築
1.
GitLab & Web
Hooks & git-flowで実現する 企業向けGit環境の構築 CROOZ株式会社 技術統括本部 鈴木 優一 © CROOZ,Inc. 1
2.
Gitが開発者もたらした恩恵 『ブランチ管理が容易 & ブランチ作成が高速』 Subversionと比較すると… ・ローカルにリポジトリを持っているため自由度が高い。 ⇒ サーバ側を気にせずブランチを切ったり、 ワークスペースを切り替えたりできる。 ⇒
ワークスペースの切り替えが超高速 ・trunk、branchesごとに再チェックアウトが不要 etc … Git が開発者にもたらした恩恵は非常に大きい! 一方、企業で開発する場合にGitだとつらい部分もある。 © CROOZ,Inc. 2
3.
企業でGitを利用する場合にツラいこと 1.Bareリポジトリが複数サーバに分散しがちになる。 展開の容易さから、開発サーバごとにBareリポジトリを 作成しがち。 ⇒ バックアップやgcなどのメンテコストが増加する。 2.ブランチの管理コストが増大する。ログが汚れやすい。 ブランチが容易に作成できる。 ⇒消し忘れ多発 &
branch作成 & merge 多発。 3.権限の管理が難しい & 管理コストが多い。 数百人分sshの鍵設定はさすがに運用きつい。また誰でも pushできる状況はオペミスを誘発しやすい。 ⇒役割毎に権限設定できないと運用に耐えない。 4.なんだかんだいっても、導入障壁が高い。 特に非エンジニア層。クライアントツールが変わることに 抵抗がある。また移行のメリットを説明しづらい。 © CROOZ,Inc. 3
4.
現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ
#2 (プロダクトA) (プロダクトB) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 認証 … RedMine (リポジトリ連携) 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare 認証 Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 4
5.
諸問題の解決案 © CROOZ,Inc. 5
6.
現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … 企業で運用するには 若干の難あり… 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ
#2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 6
7.
現行のGit関連システム連携図 情シス Active Directory 認証 アカウント管理 認証 認証 認証 … この問題を回避するには… 開発サーバ #1 2.Document Rootに展開 (local) 開発サーバ
#2 RedMine (プロダクトA) (プロダクトB) (リポジトリ連携) 管理コスト 増加 不要なブランチ 消してくれない… 担当以外のリポジ トリにPUSHでき ちゃう… © CROOZ,Inc. Bare リポジトリ が散在 3.hooksでpush Bare データ コスト増加 1.HTTPプロトコル でpush Bare Jenkins 4.ポーリング Local 5.pull 非エンジニア層 ログが汚い… エンジニア 自由すぎて 統制困難 Bare側のブランチが 意識しづらい… 自由すぎて運用しづ らい… Git移行に 消極的 意味あるの…? ツール覚え直さなきゃ… 7
8.
諸問題の解消案 1.『ルール』を制約として付ける 特にブランチ運用。自由度が高い≒統制が困難。 自由度を下げることで統制を容易に。 2.Bareリポジトリは一元管理する サーバごとにBareを置かずに一つのサーバで一元管理。 3.Bareリポジトリを可視化する 可視化することで、意識させやすくする。 ※コマンドライン以外に手軽に見れる環境は非エンジニア層に対し Gitの有用性を理解してもらうことにも役立つ? 4.権限を細かく設定できるようにする pullのみと、push可能な権限をわけてユーザに付与 運用ブランチへのmergeは開発リーダーの承認制へ © CROOZ,Inc. 8
9.
システム連携図で表すと 情シス Active Directory アカウント管理 認証 認証 開発サーバ #1 開発サーバ
#2 (プロダクトA) (プロダクトB) 認証 … 認証 RedMine GitLab 3.Document Rootに展開 (local) Bare マウント 運用ブランチへのmergeを承認 エンジニア © CROOZ,Inc. Local 4.pull エンジニア(リーダー) 1.HTTPプロトコル でpush Jenkins 3.ポーリング 2.Web hooksをpost 展開 スクリプト 認証 git-flow ブランチ運用ルールを統制 リポジトリ の状況を 可視化 非エンジニア層 まずは可視化し、 Gitの導入障壁を下げる 9
10.
自社に適応可能な ブランチ戦略 © CROOZ,Inc. 10
11.
自社に適応可能なブランチ戦略とは? 1.ベストプラクティスから学ぶ ・「A successful Git
branching model」を参考にブランチの運用 モデルを考える 2. Mergeを行う回数を減らす ・ミスの確率を減らすためには元となる母集団のMerge回数自体を減らす。 ・ミスの確率を減らすために技術的に対応できる(すべき人)にMerge操 作を限定する。 3.Mergeに対し承認のワークフローを入れる ・Mergeに対し申請、承認のワークフローを設けることでmergeを意識 的に行うように促し、結果としてmergeミスによる意図しない破壊を防 ぐ。※意味合い上のコードレビューが同時に行われる、 4.システム化できるルールとして作成する ・人のオペレーションである以上オペミスは発生するのでシステム化が行 えるルールとして作成する。 © CROOZ,Inc. 11
12.
自社ならではの制約は? 1.性質の異なる複数のプロダクトの存在 ソーシャルゲーム :リリース周期が極めて速い。 (最大で1日あたり5回なんて日も) プロジェクトのライフサイクルが短い。 コマースサイト :リリース周期が長い。 プロジェクトのライフサイクルが長い。 2. Dev環境からPre環境へのデプロイプロセス ソーシャルゲーム
:Dev環境のmasterリポジトリをPre環境の masterリポジトリにpush。 リリース周期が極めて速いため、Pre環境で問題が 発覚してもバージョンを指定してchedkoutするな ど悠長なことを行うほど余裕がなく、dev環境で修 正をかけてPre環境にすぐpush。 ※バージョンの巻き戻しは行わない コマースサイト © CROOZ,Inc. :基本はソーシャルゲームと同じ。 ただし、問題の対処が場当たり的になったりログが 汚れるので可能であればなんとかしたい 12
13.
自社のGitブランチ戦略 大きく分けて「メイン」と「サポート」の2系統 メインブランチ 開発Team以外に公開するブランチ。 ブランチには寿命はなくの開発開始からサービス終了まで存在 サポートブランチ 開発Teamのみでブランチ。 ブランチには寿命があり役割が終わると破棄 系統 ブランチ名規約 master メイン develop ブランチ v_x.x.x 役割 現在リリース中の状態を保持 最新の開発結果を保持 過去のバージョンを保持 feature/[#refs] 追加機能用 サポート release/[#refs]
リリース準備用(使用しない) ブランチ hotfix/[#refs] 不具合修正用 [#refs]には関連する作業チケット番号を記載 © CROOZ,Inc. 分岐元 マージ先 寿命 (起点) - なし - master なし master - なし develop develop あり develop master あり msater develop master あり 13
14.
ブランチの種類 ~メインブランチ~ master ブランチ 現時点で本番環境で「Pre環境」もしくは「本番環境」で利用されてい るソースコードの状態を管理するブランチ。 このブランチは develop
および hotfix ブランチからのみmergeされ、 commit は一切行わない。 develop ブランチ 最新の開発の結果が常に保持されているブランチ。 このブランチ上はサポート (feature, hotfix) ブランチからのみmerge され、 commit は一切行わない。 v_x.x ブランチ 運用中のマイナーバージョンを管理するブランチ。原則すべてのリビジョ ン(HotFix)は適応されない。 分離するメリット ・運用中のリリース資産と開発資産を分離して管理することができる ・開発中に本番環境に不具合が発生した際にmasterからソース取得可能 14 © CROOZ,Inc.
15.
ブランチの種類 ~メインブランチ~ feature ブランチ 新機能を開発する際に develop
から作成するブランチ。開発完了後に developにmergeする。 hotfix ブランチ リリース後に発生した不具合の修正や、緊急の設定変更対応などの緊急対 応時に master から作成するブランチ。開発完了後に master, develop の両方にmergeする。 release ブランチ Pre環境のorigin/masterが代行するため利用しない リリースの準備のためにdevelop から作成するブランチ。 開発完了後に master にmergeする。 © CROOZ,Inc. 15
16.
ブランチ戦略 プログラマ ~新機能開発時~ ローカルリポジトリ feature develop hotfix
master Bareリポジトリ Web UI feature develop hotfix master v1.0 ① origin develop をpull ② feature branch を作成 ③ commit ④ origin feature にpush 同時にorigin に feature branch を作成 ⑤ merge request 申請 プログラマ(PL) 承認 ⑥ develop に対し merge ⑦ feature branch を削除 © CROOZ,Inc.
17.
ブランチ戦略 プログラマ ~緊急対応時~ ローカルリポジトリ feature develop hotfix
master Bareリポジトリ Web UI feature develop hotfix master v1.0 ① origin master をpull ② hotfix branch を作成 ③ commit ④ origin hotfix にpush 同時にorigin に hotfix branch を作成 ⑤ merge request 申請 プログラマ(PL) 承認 ⑥ develop, master に対し merge & tag付け ⑦ hotfix branch を削除 © CROOZ,Inc. v1.0.1
18.
ブランチ戦略 プログラマ ~機能更新時~ ローカルリポジトリ feature develop hotfix
master GitLab Web UI Bareリポジトリ feature develop hotfix master v1.0 ① origin master をpull ② develop master をpull ③ merge対象を 確認しmerge request 申請 プログラマ(PL) 承認 v1.1 ④ master に対し merge & tag付け ⑤ develop branch をrebase プログラマ ① origin develop, masterをpull (localのbranchとmerge) © CROOZ,Inc. v1.1
19.
ブランチ戦略 プログラマ(PL) SAP ① post-receiveで 自動でソース展開 ② post-receiveで 自動でソース展開 ~Pre環境反映時~ リモートリポジトリ Pre環境 Dev環境
(SAP) feature develop hotfix master v1.1 展開スクリプト develop master sh master v1.0 v1.1 sh ③ remote 上で pre master に push v1.1 プログラマ(PL) コマースサイト Pre環境 Dev環境 (コマース) develop master ① remote 上でtag 指定でcheckout ② Pre環境上でtag 指定でcheckout © CROOZ,Inc. v1.0 master v1.0 v1.1
20.
ブランチ戦略 タグ命名規約 v_1.0[.1] ① ②③④ ⑤⑥ No 項目 説明 ①
タグ接頭辞 “v_” ② メジャーバージョン 機能追加以上の大規模な変更がある場合に0から順に インクリメントする。 新規開発時は0で、正式リリースバージョンより1と する。 ○ ③ 区切り文字 “.” ○ ④ マイナーバージョン 機能追加の際に0から順にインクリメントする ○ ⑤ 区切り文字 “.” × ⑥ リビジョン バグFixなど不具合修正や緊急対応の場合に0から順 にインクリメントする。 ⑤と⑥は作成不要 © CROOZ,Inc. 固定 必須 固定 固定 ○ × 20
21.
ブランチ戦略を実現する ための各ツール © CROOZ,Inc. 21
22.
諸問題の解消案 1.GitLab Rails製のGitHubのOSSクローン 2.展開スクリプト WebHooksを受け付けて、各Dev環境にソースコードを展開するWebの エンドポイント 3.git-flow 「A successful Git
branching model」に基づく運用を補助する Git Plugin。 ※CUIに抵抗のある人にはSourceTreeに連携させて使うことを推奨 © CROOZ,Inc. 22
23.
なぜGitLab? イニシャルコストが低く、最も要求に近いため 下記4ツールで比較 ツール名 GitHub Enterprise GitLab Gitorius Gitblit 実装 ? Rails Rails Java OSS × ○ ○ ○ インストール 容易(VMで提供) 比較的容易 若干難あり 容易 Pull Request あり 類似機能あり 類似機能あり 無し GitLab
とGitoriusの決め手はインストールの容易さ。 Github Enterpriseは年間$750,000(300名)≒約800万 購入なんてあり得ない! PHPエンジニアが圧倒的に多いので本当はPHP実装が望まし かったが、メンテする人が少ないのでRubyは覚える。 まぁエンジニアなんて一生勉強なんだからそれでいいでしょ! © CROOZ,Inc. 23
24.
GitLabの特徴 ・リポジトリブラウザ ・Merge Request ・プロジェクト毎の権限、ロール管理 ・Active Directory連携 ・コミットログ、ネットワークグラフ ・リポジトリ統計 ・Issues、Milestone ・Wiki ・Wall ・Web
API ・Web Hooks、System Hooks etc… © CROOZ,Inc. 24
25.
GitLabの特徴 ~リポジトリブラウザ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 25
26.
GitLabの特徴 ~Merge Request~ ※ 運用環境のため、画像をぼかしています ©
CROOZ,Inc. 26
27.
GitLabの特徴 ~権限、ロール管理~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 27
28.
GitLabの特徴 ~コミットログ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 28
29.
GitLabの特徴 ~ネットワークグラフ~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 29
30.
GitLabの特徴 ~リポジトリ統計~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 30
31.
GitLabの特徴 ~Issues~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 31
32.
GitLabの特徴 ~Milestone~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 32
33.
GitLabの特徴 ~Wiki~ ※ 運用環境のため、画像をぼかしています © CROOZ,Inc. 33
34.
GitLabの特徴 ~Web Hooks~ ※ 運用環境のため、画像をぼかしています ©
CROOZ,Inc. 34
35.
GitLabの特徴 © CROOZ,Inc. ~Web API~ 35
36.
メリット レビュー & 承認を行う文化の導入 Merge
Request を活用することでレビュー&承認のワークフ ローを導入し、ソースコード品質を向上。 「見られる」という意識が、汚いソースを減らすことに有効 権限 & Role制御 全従業員どのリポジトリにも全員PUSH可能な状態から脱却! 役割およびリポジトリについて個別に権限制御することでよりセ キュアに。またオペミス防止に有効 ブラウザ上で可視化 『目に見える』は非常に重要! 特に非エンジニア層にGitがオタクの道楽ではなく、組織にもたら す利益が大きいことを理解してもらいやすい © CROOZ,Inc. 36
37.
副次的なメリット Gitへの拒否反応の低下 WebUIがあり各個人がサンドボックス的に使えるため、Gitへ の拒否反応を低下させるのに有効。 実際、試しにPrivateリポジトリを作っていた人は多かった ナレッジ共有の加速 今まで開発者個々に作っていた便利ツールやスクリプトはここに しか使われていが、GitLabの活用で開発者間での共有が容易にで きるためナレッジ共有が加速 © CROOZ,Inc. 37
38.
想定利用規模 利用者数 参照のみ 参照&書き込み :約300名 :約200名 リポジトリ数 会社プロダクト用 開発者個人用 © CROOZ,Inc. :約50リポジトリ :約50リポジトリ 38
39.
サーバ構成 サーバースペック タイプ CPU メモリ :仮想 :4 Core :8 GByte OS・ミドルウェアバージョン OS Git GitLab Ruby Python Redis mysql nginx ©
CROOZ,Inc. :CentOS 6.4 :1.7.12.3 :6.0 :1.9.3p448 (2013-06-27 revision 41675) :2.7.3 :2.4.10 :5.5.31 :1.4.2 39
40.
導入直後に 発覚した課題と対策 © CROOZ,Inc. 40
41.
1.想定以上のシステム負荷 Active Directory連携ができない… 【原因】 GitLabの仕様? CROOZではGmail (Google
Apps)で電子メールを運用し ているため、Active Directory上のユーザの電子メールが 設定されていなかったことが原因。 【対策】 Active Directory上のユーザ全員にメールアドレスを設定 過去分についてはvbsで一括登録。 © CROOZ,Inc. 41
42.
2.想定以上のシステム負荷 導入直後にLA急上昇… 【原因】 想定を超える利用規模となっていたこと、および1GB近い リポジトリが同時に複数cloneされていたことが原因。 【対策】 仮想マシンへの理ステムリソースの追加 CPU 4 core ⇒
6 core RAM 8 GByte ⇒ 16 Gbyte リポジトリ中のSWFをGitからWindows Shadow Copy & Extreme Z-IP管理に移行。 移行対象は git filter-branch コマンドに--index-filter オプションを付け、全履歴までさかのぼって削除。 © CROOZ,Inc. 42
43.
3.push時にエラー発生 git push に
status code 413 が出る 【原因】 エラー内容 error: RPC failed; result=22, HTTP code = 413 要はpush するデータサイズが大きいことが原因 【対策】 GitLabのアップロード上限を変更する /etc/nginx/conf.d/gitlab.conf の client_max_body_size を500Mへ /home/git/gitlab/conf/gitlab.yml の max_sizeを52428800へ クライアントのアップロード上限を変更する git config http.postBufferを524288000へ © CROOZ,Inc. 43
44.
4.展開スクリプトがBranch非対応 Dev環境にBranchが展開できず、現場から不満増大 【原因】 今まではDev環境がBareであったため、Bare上での branch作成から Document Root
側へのソースコード 展開(ローカルリポジトリ)までを行うシェルスクリプト が存在していたが、Bareが別サーバとなったため、 Document Root 側への自動ソース展開ができなくなった ため 【対策】 展開スクリプト修正。 Web HooksでローカルリポジトリとBareのリポジトリを 比較し、新規ブランチであれば、ディレクトリを作成して clone。既存ブランチであればpullするに仕様変更。 © CROOZ,Inc. 44
45.
その後、運用してみて © CROOZ,Inc. 45
46.
実感したこと ~使わせる立場として~ ブラウザのUIは大事! 【導入前】 Bareが存在するサーバにログインし、コマンドを叩かない とブランチの一覧が取得できないため、明らかに利用されて いないものや、命名からは何をやっているかが不明なものが 入り乱れていて整理できない状態。 【導入後】 ブラウザで容易に状況が見れるので自発的に気づいて削除 してくれる。また指摘もしやすい。 またgit-flowによりブランチの命名を守らせる障壁が下がる ため管理が容易。 © CROOZ,Inc. 46
47.
実感したこと ~使う側の立場として~ 開発効率が向上!(Merge Request は偉大!) 【導入前】 ローカルでテスト後にBareのmasterリポジトリにpush。 コードレビューはpush後であったり、Dev上でのバグ発覚 により出戻りが多かったり、Dev環境での動作検証が行いに くい。 【導入後】 masterブランチにpushする前にソースレビューおよび指摘 事項の修正が可能に。 masterブランチに影響を出さずに検証も行えるため、Dev 環境上でのテスト&デバッグ効率も向上。 ©
CROOZ,Inc. 47
48.
実感したこと ~使う側の立場として~ Pre環境のリポジトリへのデプロイが楽! 【導入前】 コミットハッシュでソース差分を見ていたため、Dev環境、 Pre環境でそれぞれ最新のコミットハッシュを取得してDiff を見るため、運用が面倒 【導入後】 リリースのバージョン管理がリリースTagで行われるため、 GitLab上のTagのDiffのみ見れば差分確認が可能。 © CROOZ,Inc. 48
49.
実感したこと ~管理側の立場として~ Dev環境の設定が楽! 【導入前】 新規にBareリポジトリ作成ごとにhookスクリプトの作成が 必要。 またDev環境のリプレイスのたびにBareリポジトリの移行が 発生。 【導入後】 Web HooksのURLを設定するだけ。 またDev環境のリプレイスの際もWeb Hooks
のURL中の ドメインを変更するだけ © CROOZ,Inc. 49
50.
実感したこと ~管理側の立場として~ リポジトリのバックアップが楽! 【導入前】 Bareリポジトリが追加になる毎に、hookスクリプトで バックアップ用サーバ上のBareリポジトリpush。 リポジトリが増えるごとに設定が必要なのに加え、pushが 重い。 【導入後】 GitLabのバックアップコマンドをcronに設定するだけ © CROOZ,Inc. 50
51.
実感したこと ~その他~ Gitは意外と使われている 【導入前】 Git 利用対象プロジェクトに所属している人以外は利用して いない。 また個人リポジトリを作成する人はいない (いままでする場所がない) 【導入後】 Git 利用対象プロジェクトに所属している人以外も意外と個 人リポジトリを作成し、活用している また個人リポジトリについても想定の約2倍。 ・導入時の個人リポジトリの想定数 約50 ・実際に作成された個人リポジトリの数
約100 © CROOZ,Inc. 51
52.
残課題 ブランチ戦略 & Merge
Request 文化の定着化 メリットは大ききものの、まだ定着していない 地道に教えていくしかない バイナリ管理系のリポジトリの移行が未実施 大きすぎてGitに向かない。HTTP経由なんて非現実的 Windows Shadow Copy & Extreme Z-IPへ移行 Merge Request に気づきにくい 基本は声を掛け合ってやっているものの、たまに漏れる RSSを解析して社内のチャットツールに流す © CROOZ,Inc. 52
53.
まとめ © CROOZ,Inc. 53
54.
まとめ ・Gitは自由度が非常に高いため、何かしらの形で統制 (≒制約)しないとを企業で使う場合は運用が大変 ・Bareリポジトリを一つのサーバに統合することの メリットは大きい。 ・Pull Request がもたらす恩恵は大きい。 ・細かい課題はあるものの、GitLabでもGitHub的な ことは十分運用に耐えれる。 ©
CROOZ,Inc. 54
Baixar agora