リリースの自動化
最近は下記のようにライブラリ等のリリースを自動化している。 バージョンを入力するとPull Requestを生成 Mergeするとリリース ラベルの管理 前回のリリース以降にMergeされたPull Requestからリリースノートが自動生成されてほしい。このとき、Keep a Changelogの形式を参考に、変更点が以下の7種類に分類されてほしい。 add change deprecate fix remove security other そこで、Pull Requestに予めラベルを付けておくことで、どの節に分類するかを決定させる。またこのようなラベリングの習慣を設けることで、各Pull Requestの粒度の是正もねらう。ラベルを利用したリリースノート自動生成機能自体はGitHubが備えているので、.github/release.ymlでそのラベルを使う旨を指定すれば良い。 この
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
文化祭入退場・混雑管理システム "CAPPUCCINO" 開発・運用記
この記事は、文化祭実行委員会に所属する[1]現高校 3 年生 3 人で文化祭の入退場混雑管理システム「CAPPUCCINO」を 2 年間に渡り開発し、実際に運用した記録を残したものです。 ＊この記事は以下の 3 名による共同執筆です 著者・開発者: すばる (@su8ru / Twitter:@su8ru_) 高校３年生。普段は TypeScript に使われながらウェブフロントエンド技術で遊んでいます。 たけ (@takeno_hito / Twitter:@Takeno_hito) こうこうさんねんせい。コーディングよりはゲームのほうが好きです。上下二人に揉まれながらも一応リーダーをやってました。 ふわわあ (@fuwa2003 / Twitter:@ibuki2003) 高3。Vimmer。半言い出しっぺなのに後半コード書いてないとかで最近は肩身が狭い思いをしています。 1. CAP
スケジュールにバッファを設けるのは悪か？ - ユニファ開発者ブログ
こんにちは、プロダクトマネージャーの田嶋です。 はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑 週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！ 開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。 しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。 本記事では、R
pipとpipenvとpoetryの技術的・歴史的背景とその展望 - Stimulator
- はじめに - Pythonのパッケージ管理ツールは、長らく乱世にあると言える。 特にpip、pipenv、poetryというツールの登場シーン前後では、多くの変革がもたらされた。 本記事は、Pythonパッケージ管理ツールであるpip、pipenv、poetryの3つに着目し、それぞれのツールに対してフラットな背景、技術的な説明を示しながら、所属企業内にてpoetry移行大臣として1年活動した上での経験、移行の意図について綴り、今後のPythonパッケージ管理の展望について妄想するものである。 注意：本記事はPythonパッケージ管理のベストプラクティスを主張する記事ではありません。背景を理解し自らの開発環境や状態に応じて適切に技術選定できるソフトウェアエンジニアこそ良いソフトウェアエンジニアであると筆者は考えています。 重要なポイントのみ把握したい場合は、各章の最後のまとめを読んで頂
Trello のクローンを PHP で作りました - Qiita
機能は「カンバン」のみ Trello は有名なトヨタの「カンバン」方式を利用できるウェブアプリです。 タスク管理として、有名な「JIRA」に似た機能を無償プランで使えるという面もあり、利用されている方も多いと思います。 「カンバン」の他に、Slackなどの他サービスと連携できたり、アドオンで機能強化したり、期限を決めたり、ボードを他ユーザと共有することができます。 自分的には「カンバン」さえ使えればよかったので、このアプリで利用できるのは「カンバン」だけです。 必要があれば、個々に好きなものを入れられるよう、基本となるものを作ったつもりです。 そのため、ライセンスは MIT にしてあります。ご自由にお使い下さい。 GitHub https://github.com/mikiakira/php-simple-kanban 使っているもの PHP 5.6+ (PDO is required)
wip: 個人開発でやる気枯渇を防ぐために気をつけてること、やってること - wadackel.me
現在趣味で Web サービスを作っています。今年の 4 月末くらいから準備をし始めていたので、かれこれ 4 ヶ月くらい開発を進めています。一人きりの開発+完成したとしても実際に使ってくれる人がどのくらいいるか分からないという状況ですが、なんだかんだ楽しみながら作業できています。 まだ完成もしていないので、こんな事を書くのは的外れのような気がしますが、やる気の枯渇を防ぐために自分なりに気をつけていること+やっていることを書き出しました。既に色々な方が書いているような内容なのであまり目新しいものでは無いかもしれません、あくまでも僕なりの内容となっています。 自分が使いたいものを作る 凄い基本的なことですが、凄く大事なことのように思います。今作っているのが、主に Web サイトのデザインをアーカイブしておくための(Pinterest みたいな)サービスなのですが、少し前から欲しい欲しいと思ってい
社内の備品貸出にTSUTAYAのレジ風システムを導入した - Qiita
概要 社内の備品（主にスマホやパソコンなどの端末）をアプリで「ピッ」とスキャンするだけで、簡単に貸出/返却処理ができるTSUTAYAのレジ風システムを作りました。 その名も「ネコレジ」 OSSなテスト支援ツール「Chibineko」に続く、ねこシリーズ第2弾です。 ネコレジのシステム構成 備品を識別する仕組み 備品の識別にはQRコードを使用します。 各備品にはそれぞれ一意のIDを埋め込んだQRコードを貼り、リーダー側（クライアントアプリ）で識別できるようにします。 QRコードの印刷にはテプラPRO SR5900Pを使用。 このテプラはLAN接続対応なので、iPhoneからも直接印刷ができるスグレモノです。 ちなみにうちの部署にはスマホやガラケーなどが1,000台以上ありますが、気合いですべてに貼りました。 会員カード（通称ネコカ） ユーザーの識別も同様にQRコードで行います。 できるだけお
データサイエンティストを目指す人のpython環境構築 2016 - Qiita
pythonの環境構築について "python 環境構築"でググると20万件くらいヒットしますが、割と内容が古いです。 タイトルにはデータサイエンティストと書いてありますが、データサイエンティスト以外にもanacondaはおすすめです。 2.x or 3.x? 3.xは動かないライブラリが多いので2.x推奨 > 3.xで動かないライブラリがある、くらいまで来ました。 easy_installでpipを入れて、setuptoolsも入れて、でもwheelというのもあって... > 古いです。 virtualenv 必須 > そんなこともないです。 winでは64bitは不具合が多いので32bit推奨 > 古いです。 winでは非公式バイナリからダウンロードしてインストール > お世話になりましたが、最近は使っていません。 2016版 OS毎python環境構築法決定版 Windows: an
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
hirata.blog