GitHub Actions で簡単にバージョン番号付きリリースとリリースノートを作成する方法
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1: GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
PHPerな僕が最近気になるCIツールを調べてみたよ2014春
ツイート ブックマーク 最近だとCI使って自動テストしてます系の会社も多いのかと思います。 有名なCIとしてあるのはjenkinsがありますよね。ただ最近はJenkins以外のツールも出てきています。 そこで、ここ最近CIツールがいくつか出てきたので調べてみました。 そもそもCIツールとは？ 継続的インテグレーションを自動化するためのツールであるわけで、テストの自動化とかビルドの自動化とかが中心なツールですよね。 まあ僕はWebアプリケーションエンジニアと呼ばれるクラスタなので、ユニットテストの自動化とpushしたタイミングとかで自動的にやってくれる便利なツールぐらいの認識ですが・・・ 最近は様々なCIツールができてました。webサービスとしてでているのでCIツール用のサーバを用意したりってのもいらなくて非常に便利です。 あといろいろな言語に対応してたり、yamlで簡単に設定書けばいいとか
CIツール@福岡を主催した話 - nobkzのブログ
CIツール@福岡を主催した話 今回のエントリについて。 僕は福岡では結構いろいろな勉強会を、主催で開催してきて、実は、結構自分で、自分が主催した勉強会について、記録や評価を残したりしているが、なんか、自分の中に漬けておくのがもったいないと思うようになってきた。 なんで、公開できる範囲で、できるだけオープンにしようと思った。そして、その情報が、他の勉強会の主催、これから主催する方の参考になるようになればと思って、この記事を書こうと考えている。 とまぁ、ぐだぐだ前口上を述べたが、つまり、なにがしたいかって言えば、このブログはあるいみ、主催の失敗記録だ。失敗は反省するべきだけでは無く、今後何をしていくべきか?ということが大事であって、できるだけそういうことができればなと考えている。 ** 追記 追記1 失敗記録とは言ったが、細かいところの失敗をできるだけ書いて行こうって話でつ。まぁ、あんまり失敗
ホーム - CloneTracker
当社はCookieを使用して、お客様が当社のWebサイトでより良い体験を得られるようにしています。引き続き閲覧する場合は、プライバシーポリシーに同意したことになります。
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です。Read less
継続的インテグレーションアンチパターン
みなさんこんにちは。@ryuzeeです。 なんとなく書きためておいた継続的インテグレーションのアンチパターンをいくつか紹介します（結構ラフなメモ書き）。 頻繁にSCMにコミットしないテストコードを書かないテストコードと製品コードを同時にコミットしない定時ビルドのみでコミットビルドがない・夜間ビルドしかない帰り際にコミットしてそのままCIの結果を見ずに帰るCIでテストを通すために手作業の準備が必要メインラインのみで大きなブランチをCI対象にしていない様々な種類のテストをまとめて行っているビルドの失敗に気付かないビルドに失敗しても放置しているビルドの失敗に気づいても、修正コード以外のコードをコミットする何も変更していないのにビルドが落ちたり落ちなかったりする頻繁にビルドが失敗しているので、失敗するのが普通だと思うCIからの通知メッセージが大量すぎるCIが落ちても何も通知しないCIサーバのリソー
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充... - Sooey
GitHubのdefunktが作ったCIサーバ cijoeは、とても簡単に使えるので小さなプロジェクトではおすすめ（Jenkinsのような充実機能はありません）。 ためしに、巷で話題のamatsuda/kaminariのテストをcijoeで実行してみましょう。 まずはcijoeをインストール。 $ gem install cijoe 手元のSnowLeopard + Ruby 1.9.2だとkaminariのbundle install中にlinecacheのインストールでコケてしまうので、1.8.7を使います。 $ ruby -v ruby 1.8.7 (2010-12-23 patchlevel 330) [i686-darwin10.5.0] まず、ビルド対象のリポジトリをローカルに持ってきて、rake specが成功するところまで確認します。 $ git clone https:/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
噂のRuby&Githubなプロジェクトにスキな継続的インテグレーションサービス「Travis CI」を試してみたらすごくよかった