opsだけどgitを使ってみた～その２
こんにちは。小宮です。 前回のつづきです。今回はgitマージとタグとコンフリクトの話を書きます。 まあ初心者が慣れてきた頃の様子ということで生温かく見守ってください。 git-flowやブランチモデルがどうという話はでてきません。 git branch でブランチを切る 現在居る場所を確認する $ git branch -a add_custom_repository * master addしただけのやつがないのを確認します。 $ git status # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: ....opsだけどgitを使ってみた～その１
こんにちは。小宮です。 opsだけどgitを使ってみた～その１ということで、githubもgitlabもgitも初心者なので忘れないようにメモ。 今回はたどたどしくpushするところくらいまでにします。branch切ってみるとこは初回から書くとおなかいっぱいになりそうなので。 たぶんその２までです。その２はbranchとtagとconfrictのことを書いています。 背景とメリットデメリット ・背景 昨今の継続的インテグレーションだとかでchefでサーバ構築の需要があってその流れ弾に当たった機会を得たため、 そのリポジトリをバージョン管理する必要が生じましてgitをつかうことに。最初は会社のエンタープライズ版のgithubに保存してもらっていたんですが、 VPN経由でのやり取りの需要からgitlabの導入を行うことになりました。 ・gitのメリット ヒストリ追わなくていい。見える化。ファイル内の差分が見やすいので確認がブラウザで容易に可能になる ・gitのデメリット 同僚がつかいはじめてくれない（必要にせまられないと忙しくてスルー傾向） まあなんか気持ちはわかります。私もきっかけは半ば強制的な感じでした。 githubとgitlabの違い gitコマンド的にはあんま変わんない気もしますが、制度がオープン(エンタープライズはクローズ可)かクローズでいけるか、 gilabの場合は容量制限もディスク容量とかの環境次第でユーザ権限を細かく設定できたりなどするのがいい感じです。 もっというとVPN越しにしかつながらないようにしたいとかの自由がききます。共有Webサービスつかうか自前構築のつかうかの差です。 gilab導入の手間は最近はchefで気軽に入るレシピもあり軽減されてきたようです。 githubの場合、二段階認証をなんとかする 詳細な説明は省きますが、まずgithubに登録して会社のgithubの二段階認証をなんとかします →会社で用意していただいたマニュアルのとおりに実施。 要はgmailの2段階認証みたいなことで携帯にSMS通知が届いて認証する仕組みのセットアップです。 接続するホストでsshの鍵の作成と、作成した公開鍵の登録をgithub側のユーザプロファイルで行います。 pushするホストでgitを初期設定する まずgitコマンド打つ人のユーザ情報を登録です。 git config --global user.email "komiyay@xxxxx"` git config --global user.name "Yxxx Komiya" 設定ファイルにメモリ制限やスレッド数を指定しないとOutOfMemoryエラーが出ます。 $ vi ~/.gitconfig [user] email = komiyay@xxxxx name = Yxxx Komiya [core] packedGitWindowSize = 128m packedGitLimit = 128m [pack] windowMemory = 128m threads = 2 deltaCacheSize = 128m packSizeLimit = 128m ※m1....source treeを使ってgitlabを触ってみる（1）
おはようございます。インフラの宮下です。 社内で稼働中のgitlabがあるのですが、CLI使える人が少ないせいかgitしている人が思った以上に少ないのに困ってます。 最近はWindowsのツールでも充分にGitの体験が出来るようですので、今回は「SourceTree」を紹介したいと思います。 アンチCLIの方は「SourceTree」でも十分git操作可能ですのでまず手始めに利用してみては如何でしょうか。 そもそもGitの意味がわからないという人はごめんなさい。いずれgitの構築も誰かが書いてくれると思いますので今回は割愛します。 git知識としてはとってもわかりやすい下記サイトをご覧ください。 サルでもわかるGit入門 バージョン管理システム入門 分散型バージョン管理システムなので、みんなで使ってたまにはデグレしたりと苦い経験をしておいた方が良いと思ってます。 バックアップとかしっかりしておけば傷は浅く済むと思います… chefと連携しても良いと思いますし、configを管理してバージョンや差分を管理するでも良いですし、単にreadme的な手順を管理するでも何でも用途は良いと思います。 １）SourceTreeをインストールする Source tree公式サイトから今回はwindows7版のファイルをDownloadします。 ダウンロードした実行ファイル「SourceTreeSetup_1.6.13.exe」をダブルクリックしてインストールを開始します。 ほぼ流れにのってインストールするだけで終わります。 「グローバル無視設定ファイル」の作成を聞かれますが「Yes」「No」今の所どちらでも良いです。 今回は「Yes」にして進みます。 publicのリポジトリ設定をすると接続する事が出来ます。アカウントがあればアカウント・ユーザ名・パスワードを入力してください。 今回の用途は自社内のgitlabとの接続なので「スキップ」します。 最後にSSHキーの読み込みをするか聞かれます。既に持っている場合は登録しても良いですが後でも出来るので「No」としておきます。 ２）SSH鍵を作成して登録 gitlabにつなぐ為に作業PCの鍵を登録します。 SourceTreeを起動してまずはSSH鍵の作成と登録を行います。 既に作成した鍵がある場合はあえて作成する必要はありません。 「ツール」→「SSHキーの作成/インポート」でPuttyKeyGeneratorを起動します。 「Generate」をクリックしたらマウスをたくさん動かしていると鍵の作成が完了します。 公開鍵は「Save public key」クリックしgitlab-test.pubとして保存します。 秘密鍵は「Save private key」クリックしてgitlab-test.ppkと保存します。 ※セキュリティ上、key passphraseを入れた方が良いですよ。 最後に秘密鍵の登録を行います。「ツール」→「オプション」の「全般」からSSHクライアントの設定の所に先程保存した秘密鍵を指定します。 予想以上に長くなってしまいましたのでgitlabとの接続は次回にします。 とってもわかりやすいsourcetree導入支援サイトさんです。 あおたくノート SourceTree for WindowsからGitを利用する...DevOps時代のアジャイルでスケーラブルな開発環境をVagrant, GitHub, Travis, Chef, OpsWorksで構築する
どうも。久しぶりです。 デベロッパーの平形です。 このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。 とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。 はじめに 私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。 この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。 この記事は以下の方には不向きです。 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。 これらに該当する方。お疲れ様でした。出口はこちらです。 この記事は以下に該当する方に是非読んでいただきたいです。 開発者、インフラ担当者の方。 これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。 サーバーの台数が多くなったらどうしよう。と悩んでいる方。 開発要員が急に増えたらどうしよう。と悩んでる方。 DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。 上記を実践してみようとしたけど、挫折してしまった方。 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。 本番反映が怖くて会社に行きたくない方。 サーバーが落ちる事が不安で夜も眠れない方。 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。 それでは、夢の扉を開きましょう。 レガシーな開発と運用 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。 公開環境のサーバー増設は１台ずつ手動でキッティングしている。 パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。 バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。 これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。 現代の開発と運用 現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。 素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。 近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？ バージョン管理 環境構築 セキュリティパッチの適用 バージョンアップ オートスケール 自動テスト 自動デプロイ 開発環境の配布 なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。...GitHubでpush時にAWS OpsWorksで自動デプロイする方法
開発の平形です。 今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。 OpsWorksはAWSで提供されているデプロイのサービスです。 ＊OpsWorksについては、こちらのサイトが詳しいです。 この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。 OpsWorks自体、最近触ったばかりですが、 デプロイがすごく簡単にできるという事はよくわかりました。 でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。 普段、ソースはGitHubでバージョン管理しているので、 GitHubにpushしたら同時にデプロイできないのかな？と。 そしたら、ビックリするほど簡単に実現できました。 GitHub側で設定が可能です。 アプリケーションのリポジトリのページの「Settings」 「Service Hooks」 AWS OpsWorks 以下の項目は全て必須なので、全部入力します。 ここで、OpsWorks側の情報が必要になります。 まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。 手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。 次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック OpsWorks IDがApp Idです。 Branch Nameはリポジトリのデプロイしたいブランチ名を指定。 AWSのアクセスキーとシークレットキーを入力し、Update settingsをポチっとします。 あとは、該当ブランチにpushするだけ！ これで自動的にOpsWorksのデプロイが走ります。 僕はこれに感動しました！ ただ、欲張りな僕はまたまた思ったのですね。 OpsWorksではスタックを本番環境とステージング環境と分けて運用してるとします。 そうすると、 releaseブランチはステージング masterブランチは本番 にそれぞれ自動デプロイできたらいいなー、と。 しかし、一つのリポジトリにつき、一つのスタックの設定しかできないんですよね。 という事で「できない」という事がわかり、取り乱しました。 まあ実際の運用で、masterのpushしただけでいきなりデプロイするのもトラブルの元になりそうだし、 そういうもんなんだ。って自分に言い聞かせて落ち着きを取り戻しました。 それでも便利には変わりないですけど。 あなたのデプロイライフがもっと充実しますように。 以上、平形がお届けしました。...gitでクローンと同時にサブモジュールを初期化、アップデートする
こんにちは。 開発の平形です。 初投稿になります。 Gitでcloneした後に、何かが足りなくてうまく動かない事がよくあります。 そして気づくのです。 あ、submoduleをクローンしてねーじゃん！ ※submoduleについてはこちらの記事が参考になります。 このパターン何回目だよ！ と自分が嫌になってしまいます。 そしていつも、 git clone git://github.com/foo/bar.git git cd bar git submodule update --init --recursive といったお決まり作業をする訳です。 でもついつい忘れてしまうんですよね。 で、調べてみるとちゃんとあるんですね。 git clone --recursive git://github.com/foo/bar.git これで、クローンと同時にサブモジュールもクローンされます。 通常のクローンと使い分ける必要も特にないので、これからはこれを使っていこうと思います。 読んでいただいてありがとうございました。 まだまだ、寒い日が続いておりますが、お体にご自愛くださいませ。 参考にしたページ http://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules...