Visualizing the CPython Release Process
Below are the high-level steps (with numbers corresponding to the above diagram) in the order they occur during the CPython release process: Freeze the python/cpython release branch. This is done using GitHub Branch Protections. Update the Release Manager's fork of python/cpython. Run Python release tools (release-tool, blurb, sphinx, etc). Push diffs and signed tag to Release Manager's fork. Git
インフラのリリース自動化戦略とその行き着く先 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、@ueokandeです。 本番リリースってドキドキしますよね。 本日はkintone.comのリリース自動化と、その戦略についてお話します。 kintone.comのCI/CDパイプライン kintone.comのインフラ構成はモノレポで管理しており、AWSの構成や、Kubernetes上にデプロイするサービスなどが1つのレポジトリに存在します。 現在のkintone.comは、開発環境、ステージング環境、本番環境の3つがあります。 適用タイミングをずらすことによる環境間の乖離を防ぐため、各リリースはすべての環境に適用することとしました。 開発環境でしばらく寝かせたい変更は、機能フラグやカナリアによって切り替えます。 CI/CDパイプラインは以下のようになっています。 それぞれの環境に順に適用し、本番環境適用後にテストが通れば無事リリース完了です。 kintone.comのCI
プロダクトのリリースまでの時間が268.5hから54.5hに！ VSM(ValueStreamMapping)時短術 - DMM inside
プロダクトのリリースまでの時間が268.5hから54.5hに！ VSM(ValueStreamMapping)時短術
Goツールのリリースエンジニアリング | おそらくはそれさえも平凡な日々
前回: Goツールのリリースにおけるバージョニングについて 前回挙げた以下のリリース5段階の中で、バージョニングだけで1エントリになりましたが、今回は、2,3について。 versionをbumpする CHANGELOGを更新する 1,2での変更をgitに反映してタグを打つ ビルドする ビルドをアップロードする 具体的には、リリースに纏わるファイル更新をgitに反映さえてタグを打つところまで。ビルドする直前までとも言えます。 CHANGELOG.mdを自動更新する CHANGELOGは ghch で自動生成させている。規定の CHANGELOG.md をリポジトリに配置して、 % ghch -w -N $next_tag とすれば、魔法のように CHANGELOG.md を更新してくれる。生成された CHANGELOG.md はこんな感じ。 https://github.com/Songmu
goxc + ghrを使って、Goで書いたツールのバイナリをGithub Releasesで配布する - $shibayu36->blog;
先日の goreleaserを使ってGoで書いたツールのバイナリをGithub Releasesで配布する - $shibayu36->blog; で、Goツールのバイナリ配布ができるようになった。しかし、アーカイブ周りの処理が少し期待と違い、作成したzipをunzipコマンドで取り出すとファイルのアクセス権がおかしくなり、バイナリに実行権限がつかなくなるという問題が起こった。これは困る。 goreleaserを深追いをしても良いけど、ひとまず別の方法も試してみようと思って、goxc + ghrを使うようにしてみた。これがうまくいったので、メモしておく。 今回のコードは以下のところで確認できる。 https://github.com/shibayu36/shibayu36/tree/v0.0.7 https://github.com/shibayu36/shibayu36/pull/1 バ
リリース用モジュールのチェックツールを作ってみた - Qiita
背景 Webシステムをリリースする際、私が携わっているプロジェクトでは以下の操作を行っています。 Gitでdevelopブランチの内容を、releaseブランチにマージ releaseブランチにチェックアウト リリース用の設定がなされていることを確認。 warファイルを作成 リリース用の設定がなされていることの確認項目は、10~20個です。たとえば、以下のような項目です。 DB接続先 FTPやDBなどのパスワード（テスト環境と本番環境はパスワードを変えている。間違って本番環境にアクセスしないようにするため） 画面に「テスト環境」という文字が表示されていない リリースの頻度は3ヶ月に1回なので、確認自体はそこまで負担ではありません。 目視確認では漏れる恐れもあるため、勉強も兼ねてツールを作ってみました。 まあ、ツールが間違っているという可能性もありますが。。。 ツールの中身 構成 JUnit
Debug構成とRelease構成の違い - tekkの日記 C#,VB.NET
ビルド構成の Debug と Release の違いについて調べてみました。 開発中だから Debug 構成、リリースする時は Release 構成という 固定観念 ではなくて、開発中とリリース時での動作に一切の違いがあってはいけないから安全に動作することを最優先にリリースする際も Debug構成で行く！という選択肢もあっても良いと思います。パフォーマンスが気になるアプリでは説得が難しいと思いますが、そもそも Debug 構成で性能要件が満たせないようなら設計レベルから見直すべきだとは思います。Release 構成による最適化のパフォーマンス向上は、最後の切り札くらいに考えても良いのではないでしょうか。 というわけで、以下が Debug 構成と Release 構成の違いです。 Debug 条件付きコンパイルの定数：DEBUG,TRACE コードの最適化：ON デバッグ情報：FULL Re
Mackerelの告知を出すときに最近気をつけていること - Mackerel お知らせ #mackerelio
こんにちは。はてなシニアエンジニアのid:daiksy です。 Mackerelをご利用いただいている皆さんは、ぼくのidを見て「おや？」と思われた方もいらっしゃるのではないでしょうか。 ぼくは、金曜日のMackerelのニュースレターとブログ告知記事の執筆を担当しています。 今回は、Mackerelの告知やニュースレターで最近始めた取り組みについてご紹介いたします。 毎週金曜日に告知とニュースレターを出す Mackerelではリリースから現在まで、60週以上にわたり毎週のリリースを継続しています（年末年始の1週間だけお休みしました)。 不具合の修正や内部的なロジックはもちろん継続的に改善しているので、毎週リリースが行われているという事自体は特に珍しいことではありません。 ここでいう"60週以上連続"というのは、ユーザーの目に触れる新しい機能をこの期間ずっと続けてリリースをしている、という
安全なリリースのために心がけていること - クックパッド開発者ブログ
こんにちは。会員事業部の高田です。今回は安全にリリースをするために、アプリケーションエンジニアとして心がけていることについて書きます。 クックパッドではなるべく早くユーザーに価値を届けることを大切にしているため、1 日に何度も安全にリリースできるしくみや、リリース後に発生したエラーにすぐに気付けるしくみがあります。しかし、アプリケーションレイヤーの問題はアプリケーションエンジニアが気をつけなければいけません。私個人としては、少し気をつければ防げた問題を起こしてユーザーや会社に迷惑をかけてしまった経験があるため、注意深くなっています。 プロジェクトの大きさや目的はさまざまあり、早くリリースして検証したい施策などもあると思います。今回は慎重にリリースしたいプロジェクトの例として、有料会員の解約の前に特定のユーザーにのみクーポンを配布するという架空のプロジェクトを元にお話します。 1. 準備 リ
Androidアプリを新規リリースする際のあれこれ - クックパッド開発者ブログ
こんにちは、投稿推進部の吉田です。 少し前に、お料理アルバムという「日々の料理を写真を記録する」ためのアプリのリリースしました。初めて会社のプロダクトのリリース作業を経験して、色々と学びがあったので共有したいと思います。 見出し releaseビルドをCIで作成する releaseビルドから不要なモノを排除する Google Playストアのリファラを活用する Google AnalyticsとGoogle Playストアの連携をする リリース直前チェックリスト releaseビルドをCIで作成する リリース版apkはコマンドから生成できる環境を整え、CIで作成するのがお薦めです。 CI上でのビルドすることで、ビルド手順の共有が不要になり、開発チームの誰でもボタン一つでビルドが可能になります。 また、ビルドをCIに任せることで、keystoreとパスワードを開発者全員に共有する必要がなくな
maven central にリリースしてみた - tokuhirom's blog
Maven central にあげようと以前奮闘してみたが､うまく行かずに諦めていた｡ アカウントの登録まではいっていたのだが､なんかうまくいかなくて諦めていたのだ｡ が､モリスさんのエントリを見ながら pom を設定していったら今回はなぜかうまく出来た｡ http://d.hatena.ne.jp/tagomoris/20141028/1414485679 Maven central は難しいか? Maven central にアップロードするまでに間には以下のようなステップが必要になる｡ JIRA にサインアップする JIRA でパッケージに対するアップロード権限を要求する gpg の設定をする settings.xml/pom.xml をセットアップする mvn release:prepare release:perform する このうち､最初の JIRA へのサインアップは難しい
Androidアプリの段階的リリース - ninjinkun's diary
Androidアプリは全体の5%のユーザーに公開するというような、段階的公開が可能です。会社でこの機能を使っているので、知見をまとめました。 目的 致命的な問題 (e.g. 商品が出品、購入できない）に全ユーザーを巻き込むのを避ける 不具合を減らしつつ、リリースサイクルのスピードを保つ 問題 母集団が少なすぎると問題が見つからない or 報告されない場合がある 変更できるのは公開するユーザーの割合のみ できる限り不具合にユーザーを巻き込まないようにしながら、早めに段階を上げるという問題を考える 戦略 プラン 松 変更点が多い場合、致命的なバグが発生する可能性がある場合 5 or 10%からリリース 最短で5日で全ユーザーにリリース (竹は考えてなかった…) 梅 変更点が少ない場合 20%からリリース 最短で3日で全ユーザーにリリース 運用 リリースの翌日に不具合の有無を確認して、大丈夫そう
Release note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -
昨日 Changelogのための英文テンプレート集 - ぴょぴょぴょ？ - Linuxとかプログラミングの覚え書き - というエントリを書きましたが，その際 apple や microsoft が出すような Release note と，いわゆるオープンソースなプロジェクトが出す release note や changelog とでは英文の書き方が異なることに気が付きました．蛇足気味ですが，興味深かったので別エントリとしてまとめます． ポイント 不具合を，不具合と言わない bug，problem，fix といった単語は，他の言葉で言い換えます 旧製品も完璧だったが，新製品はもっと良い製品だよという言い回しが基本です．会社的に不具合を認めると面倒ですからね． 免責事項を強調 良く使う単語 issue (problem, bug の言い換え) update, improve, address
LINE Serverの開発とリリースプロセス « LINE Engineers' Blog
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
maven releaseプラグイン メモ – release をやり直したいときは？ – yusuke.blog
$ git reset –hard HEAD^ $ git reset –hard HEAD^ $ git tag -d リリースバージョン名 Deleted tag '2.1.3' (was 247b341) $ git push origin :refs/tags/リリースバージョン名 To git@github.com:yusuke/twitter4j.git – [deleted] 2.1.3 $ git push -f origin master $ mvn release:prepare -Darguments="-Dmaven.test.skip=true" INFO] Scanning for projects… [INFO] Reactor build order: [INFO] twitter4j [INFO] twitter4j-core [INFO] twitter
Automated Deployment with Maven - going the whole nine yards
Automating your build process with Continuous Integration is certainly a great idea, but why stop there? Why not go the whole nine yards and automate the deployment process as well? Staging and production deployments are typically more complicated and more involved than a simple development deployment, but doing them by hand can be time-consuming, tricky and error-prone. Indeed, turning your stagi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - lanwen/github-release-badges: Shortcut for creating release badge for github using shields.io and heroku