まえがき
Habrを駆け巡ったとき、驚くべきことに、継続的インテグレーションと継続的デリバリー、さまざまなGithubインテグレーション、HipChat（Slack）-CI-連続的デリバリーによるステージングとプロダクションなどの精神で、さまざまな魔法の癖を使った本格的なチームワークフローに関する記事が1つも見つかりませんでした。私はただ検索できないかもしれませんが。
しかし、それでも、仕事の経験はほとんどありませんが、同じプロジェクトで一緒に作業しているチームの生活を楽にするさまざまな利点、これらすべてを1つのデバッグシステムに結合し、腰の不快感を軽減する方法について話したいと思いましたプロジェクト作業時間。
だから、カット-CIサービスSemaphoreAppの分析、他のサービスとの統合について、そして私たちの生活を簡素化する他の喜びについて少し。
エッセンス
多くの紳士がすでに私に説明しているので、CIが何であるか、なぜそれが必要なのか、その他の一般的なことについては詳しく説明しません。ここで、 「継続的インテグレーションの紹介」
そして今、主なものに-Railsアプリをセマフォに接続します。
私たちの素晴らしい仕事は、直感的な登録を行うことですが、それでもコメントと写真を使って行います。
サインアップ
私たちはsemaphoreci.comにアクセスします。クールな男は、実稼働環境にどれだけクールに展開しているかを自慢しています。
GitHubとBitbucketから選択できます。 実際、セマフォはアトラシアン製品の多くをサポートしています-Bitbucket、Hipchat、Jira。
そんなに悪くない。
次に、ビルドするプロジェクトとブランチを選択します。
プロジェクトの初期設定を行うよう提案されます。 提案されている言語には、Ruby、Clojure、JS、PHP、Go、および神話言語「その他」があります。
使用するデータベースにはバリエーションがあります。
そして、それだけです。 独自のCIがあります。5倍{puts 'hooraaay！' }
実際、最も単純なことはボタンを突くだけです。 他のサービスとのすべての統合の複雑さは、CTRL + CおよびCTRL + Vを押す能力に依存します。 さて、英語で読んでください。 自信のあるPCユーザー、会計士翻訳者のレベル。
そして、ちなみに-GitHubとBitbucketとの統合はすでに行われています。 ビルドが失敗した場合でも、プルリクエストをマージできます。 そして、骨組みのために、チームリーダーから耳を傾けてください。
ちなみに、競合するブランチがある場合、ビルド後、最後のブランチでも、Semaphoreはgit rebase -i your_integration_branchを実行してすべての競合を修正するまで、競合するPRを制御できません。
あなたが青信号を持っていて、右のチームのように、彼らがあなたのプルリクエストをレビューし、OKを設定した場合-あなたは大切なボタンを押して、翌日のスタンドアップを自慢できます。
コミュニケーション
それでは、システムの次の部分、ビルドの成功/失敗、およびチーム内のコミュニケーションに関する通知に移りましょう。
バリエーションの塊、私はちょうどHipChatまたはSlackを提案しました。 理由-両方とも無料で、Slackは見た目は良いが、統合が限られている（5つのみ）、その小ささはHipChatよりも小さい。 HipChat-統合は無制限ですが、一般的には-同じSlackだけが退屈に見えます。 トレンディなスタートアップ向けではありません。
Hipchatの1つの部屋で行ったすべての統合の小さな例。
実際、プロジェクトで起こったことのすべてのログがあります。 そして、そこに統合できるのはこれだけではありません。 Airbrake、NewRelicアラートなどのエラー。
これで、Semaphoreの機能を確認できます。 スタジオの設定のリスト。
ビルド設定、構成、ENV変数、リポジトリに関する情報、ビルドの優先ブランチを設定、スケジュールに基づいてビルドを起動（理由が分からなかった）、展開（少し後）、メールの通知を設定する[通知]タブヒップチャットルーム/スラックルーム/他の場所など。
Hipchatについては、HipChatの設定で簡単に生成されるルーム名、またはルームID、およびトークンのみを知る必要があります。 運転する価値があります-通知サービスの準備ができました。 かんたん
もちろん、別の場所にアラートを設定する必要がある場合は、Webhookがあります。
継続的な展開
しかし、おそらく、Herokuでの継続的デプロイのメモに関する私の話を完了する価値はあります。
HipChatインテグレーションを含む図の中の紫色のメッセージは、Herokuからのデプロイの成功に関する通知でした。 彼は手で何もしませんでしたが、彼は私のプルリクエストを単純に制御し、それはレビューをパスしました。 セマフォは私のためにすべてをしてくれたので、このサービスの使用を提案した成功した叔父として自分自身を想像することができます。
すでにRailsアプリケーションがあり、Herokuサーバーがあり、ワークフローがブランチの作成、機能の作成、テストの作成、ブランチでのテストの実行、統合でのブランチの実行、すべての統合テストの実行であるとします。 成功した場合-git push heroku。
実際、ワークフローを説明するよりも、Continuous Deliveryを使用したステージングにプッシュする方が時間がかかりません。
統合-設定、展開タブ、サーバーの追加から始めましょう。 選択肢が提供されます。
私はherokuに決めました。あなたの選択はあなた次第です。 次に、展開の種類（自動または手動）を選択できます。 最初の展開はeach_successful_buildです。これは、ビルドが成功しなかった場合、どこにも到達しないことを意味します。2番目の方法は、ビルドをサーバーに送信するボタンをクリックして、赤いボタンのあるブリーフケースを提供します 私たちは怠け者であり、さらに、サーバーはステージングと見なされますが、ステージングのために自動ステージングされます。 本番の場合は、ボタンの方が適しています。
次に、デプロイ用のブランチを選択し、Heroku APIキーを入力するよう求められます。 そしてそれはそれ自体ですべてを行うことができます。
また、herokuのアドオン-展開フックを配置することもできます。これには、展開の成功または失敗を通知するHipChatフックがあります。 ビルドが失敗した場合、失敗した展開はありませんが、繰り返します-展開はありません。
誰かが役に立つといいな。