Software. Faster. GitLab is the most comprehensive AI-powered DevSecOps Platform.
はじめまして。ぐるなびでサーバインフラエンジニアを担当している遠藤です。かれこれ8年以上在籍しています。 この記事では「GitLabとRancherで何ができるか」「ぐるなびではどう使っているか」 について書こうと思います。 ひっくるめて「ぐるなび×GitLab×Rancher」とタイトルを付けました。実は「Rancher Meetup Tokyo #13 (GitLab x Rancher特集)」というイベントで、全く同じタイトルで登壇させていただいたことがあります(そのときの資料はこちらで公開しています)が、今回の内容はこのブログのタイトルの通り、その内容を深堀りしたものになっています。 GitLabやRancherについてある程度ご存知の方は「GitLabとRancherの連携」からお読みいただいても問題ありません。内容は以下になります。 GitLabについて GitLabとは ぐる
GitLab.com、200TB超のデータとともにAzureからGCPへ移行完了。三度の計画停止による予行演習を繰り返し、移行手順も公開 ソースコード管理サービスを提供するGitLab.comは、GitHubの競合として見なされています。そのため、今年の6月にマイクロソフトがGitHubを買収するとの報道の際には、大手企業の傘下にない独立したGitサービスの提供元として突如として注目度が上昇していました。 参考:GitLabへのインポートが普段の10倍に急増、GitHubの買収報道で その同じ6月、GitLab.comはこれまで同社のサービスを提供する基盤として利用してきたMicrosoft Azureから、Google Cloud Platformへ移行することを発表します。 I wrote a post about @gitlab's project to migrate our SA
2020/12/10 「OpenShift Commons Gathering Japan 2020」 で利用した資料です。 動画もありますので、よかったら見てください。 https://www.youtube.com/watch?v=WsR3YZfdNZg&list=PLaR6Rq6Z4IqeNLyWM4J_IyOgSofhJ-RAo&index=14 #openshift #ArgoCD #Tekton **OpenShift Commons Gathering Japan 2020 https://www.redhat.com/en/explore/openshift/commons-gathering-ja
本連載は、コンテナ仮想化技術を使ったアプリケーション実行環境構築プラットフォームである「Docker」をつかって、ソースコードのバージョン管理ツールや継続的インテグレーションツールなどの開発支援ツールの導入を行う手順をご紹介します。前回の連載では、オンプレミス環境とクラウド環境にDockerの実行環境を構築する手順と、構築した実行環境で継続的インテグレーションツール「Jenkins」の環境を構築しました。今回は、ソースコードのバージョン管理ツールである「GitLab」の環境を構築する手順をご紹介します。 対象読者 本記事は、次の方を対象にしています。 ネットワークやLinuxの基礎知識がある方 Dockerの概要を知っている方 オンプレミスサーバ(物理サーバ)にLinuxのインストールができる方 Amazon Web ServicesのEC2を利用したことがある方 Webシステムをチームで
追記(2016/1/20) タイポしてたみたいですね、すみません。 「Redmineに Redmine Github Hook Pluginをインストールする。」の項目で、redmine_github_hook.gitのurlをミスっていたようです。 指摘してくれた方、ありがとうございます。 前提 RedmineとGitlabが別サーバで用意されている。 Gitlabへgitユーザが存在し、developerグループへ所属している。 ファイルパスなどはデフォルトのものを利用しているので、適宜読み替えてください。 Redmineに Redmine Github Hook Pluginをインストールする。 次のコマンドを実行。 cd /opt/redmine/plugins git clone git://github.com/koppen/redmine_github_hook.git to
こんにちは、河野です。 一昨年にgitについての社内勉強会を行い、その内容を gitの勉強会「はじめようgit」を行いました にてまとめました。それから1年半ほど経ったので現状をまとめようと思います。 ワークフロー git flow、GitHubフローを参考に始めましたが、現在は develop,master,各feature以外に、stagingブランチを設けるようにしています。 自分がいるチームは、SIのプロジェクトが中心なので頻繁にリリースすることはありません。ですので、 各featureブランチで機能を開発→developへマージ 社内のテストはdevelopを中心に行う→テストが一巡したらstagingへマージ お客様確認用のステージング環境へはstagingブランチを使用 ステージング環境でのテストも終わったらmasterへマージ 最新のmasterをリリースし、タグを打つ と
Git, GitHub, GitLabそれぞれの特徴 *注意事項:当初は、GitHub Flowを入れる想定で調べていましたので少しGitHub Flowとの比較の観点が強いです Git Flow 使用するブランチ master マイルストーン用のブランチ develop 開発用のブランチ feature 機能追加用 (hot)fix 不具合修正用 release リリース準備用 Git Flowの良さ fix(不具合)の数が一目瞭然 masterを見ればマイルストーンの遷移が一目瞭然 参考:git-flowとプロジェクトの運営 Git Flowのまずさ ほとんどのツールがデフォルトでmasterブランチを表示するが、わざわざdevelopブランチに切り替えないといけない hotfixブランチをdevelop, master共に反映しなければならない点が面倒 参考:【翻訳】GitLab f
環境は2014/4/25時点で全て最新のものを使用。 CentOS:6.5 Redmine:2.5.1 Ruby:2.1.0 nginx:1.6.0 以下のサイトを参考にさせて頂きました。 ありがとうございました。 Redmine 2.5をCentOS 6.5にインストールする手順 http://blog.redmine.jp/articles/2_5/installation_centos/ CentOS 6.3にRedmine + Unicorn + nginxな環境を構築する手順 http://qiita.com/s-yamaz@github/items/5b32919ea33caddbca82 SELinuxを無効にする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く