Documentation Drone by Harness™ is a modern Continuous Integration platform that empowers busy teams to automate their build, test and release workflows using a powerful, cloud native pipeline engine. Installation Guides See All GitHub GitHub Enterprise Gitee Bitbucket Bitbucket Server Gitea Drone comes in two distributions: the Enterprise Edition and the Community Edition. If you only want to dow
Boost Dev Team's Productivity Enforce Your Rules and Automate Your Workflows Get Started Free ruleset: label_bugs: name: "Label issues as bug" events: [ issues ] label: bug when: - body contains "[x] Bug" - action = "opened" or action = "reopened" missing_version: name: "Close bugs with missing version number" events: [ issues ] close: true label: invalid message: > @{{ user.login }}, please re-op
タイトルは若者エントリメーカーで生成しました。 コミットステータスというのは GitHub の API で特定のコミットに success/failure/pending のステータスを与えることができるやつで、例えば CI でテストした結果がプルリクエストのウェブ画面で確認できる。誰でも見たことあると思う。 業務でも使ってるけど、git push したあとにいちいち結果を確認するのが面倒だったので、ターミナルから確認できるようなのを作った。 プロンプトに表示するとこういう感じで✓が確認できて便利(最後に設定例があります)。 インストール・使い方 % go get github.com/motemen/github-commit-status-mark 普通に起動すると現在のリポジトリの最新のコミット(HEAD)のステータスを GitHub から取得してきて、色付きの文字で表示する。 この
継続的デリバリーの8つの原則1. ソフトウェアのリリースやデプロイのプロセスは繰り返し可能であり信頼性が高い必要がある。このことは2つめの原則にたどり着く。 2. 全てを自動化する!手動のデプロイは決して繰り返し可能で信頼性が高いことには成り得ない。 あなたは繰り返し行う全てのタスクを自動化することについて本気で投資する必要がある。そしてこうすることによって信頼性に繋がっていくのだ。 3. なにか難しかったり苦痛なことがあったら、それを何度もやってみる表面的には、ばかげた話のように聞こえるかもしれない。しかし基本的にこれが意味していることは、苦痛であることを頻繁に行うことは、あなたがそれを改善し、多分自動化する方向に導いてくれるはずだ。そして最終的には苦痛がなくなり容易に行うことができるようになるだろう。 データベースのスキーマをデプロイすることを例にとってみてみよう。もしこれがトリッキー
みなさんこんにちは。@ryuzeeです。 Kelly Waters氏の7 Reasons why Continuous Delivery needs to be a BUSINESS initiativeより継続的デリバリーが必要な7つの理由について抜粋・意訳にてご紹介します。 アジャイルやリーンなチームにおける鍵となるプラクティスの1つに継続的デリバリーの考えがある。 たとえ継続的ではなくても、すくなくともとても頻繁にだ! ThoughtWorksでは継続的デリバリーに関する専用のWebサイトを提供しており、継続的デリバリーが本当に意味するところは何なのか、なぜそれが重要なのか、どうやればいいのかなどについて原理原則に基づいて話しているとても興味深いWebinarなどもある。 継続的デリバリーは技術的プラクティスではあるが、その利点は技術チームやプロジェクト全体だけにとどまらない。 継続
継続的デリバリを導入しようとする前に、いくつかの準備が必要です。真っ先に必要なのは、ビルドサーバに合うソースコード管理システムです。ビルドサーバは継続的統合を実施するサーバにもなります。ひとつひとつのチェックインをビルドできるサーバでなければなりません。一般的に言って、この用途では“既成”のビルドサーバが欲しくなります。チェックインを監視して、自動でビルドをする仕組みを構築するのは、想像以上に大変です。利用しているソースコード管理システムにフックできるトリガがあるとしても、ビルド失敗時の通知機能のような他の機能を実装するには割に合いません。 リソースが限られているとしても、継続的デリバリにとってステージングサーバは重要です。ステージングサーバは本運用環境に可能な限り似せておく必要があります。ここで第一の問題は“予算がいくらあるか”ということです。本運用環境のデータベースサーバがとても高価な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く