Goのリリースプロセスとブランチ戦略 - YAMAGUCHI::weblog
はじめに こんにちは！Google Cloudでオブザーバビリティの担当をしているものです。CVE-2021-44228のおかげでバタバタしていますがみなさんはお元気ですか？ このエントリーはpyspa Advent Calendar 2021の15日目の記事です。昨日は @moriyoshit さんの「Goのロギングライブラリ 2021年冬」でした。めちゃめちゃ調べてあって良い記事でした。Goでログライブラリの選定をする際にはこちらをまず読むと良さそうです。 2021.12.21 追記: 穴が空いていたのでGo Advent Calendar 2021 その1の14日目の記事にもしました。 さて、今日は本当は「Goならわかる確定申告第三表」という記事を書こうと思ったのですが、まだ確定申告の時期ではないのでそれは辞めにします。そのかわり、今日はGo 1.18がめでたくベータ版リリースとなっ
Gitのワークフローについての私のスタンス | おそらくはそれさえも平凡な日々
Gitのワークフロー、好みが分かれる分野で自転車置き場の議論にもなりがちだと感じている。基本的にはプロジェクトの流儀に素直に従い、余計なストレスを抱えないのが良いと考えている。例えば、私はマージコミットを作るのが好みだが、OSS活動等では「squash & mergeして」って言われることもあり、そういうときは当然素直に従うようにしている。 ということで、私のGitのワークフローについてのスタンスについて書いておこうと思う。私と一緒に働く人や、働くことを検討している人の参考になればと思います。もちろん、この辺りは、良い方向に変化もさせていきたい。例えばエントリー内でも触れていますが、私は昔はforce pushを禁止したいくらいでしたが、今は使っても良い、と思うようになりました。 Natureの特にGoでのバックエンド開発はこれに近い感じだとイメージしてもらえればと思います。ただ、できてな
"Linuxの生みの親"トーバルズ氏：「私はもうプログラマーではない」
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 石橋啓一郎 2019-11-01 07:30 Linuxの生みの親であるLinus Torvalds氏は、もう講演はしていない。フランスのリヨンで開催された「Open Source Summit Europe」で同氏が行ったのは、友人であるVMwareの最高オープンソース責任者Dirk Hohndel氏との対話であり、同氏は以前もこの形式で登壇している。Torvalds氏はこの基調ディスカッションで、自分はもはやプログラマーではないと考えていることを明らかにした。 では、誰もが「プログラマーの中のプログラマー」だと考えている同氏は今、何をやっているのだろうか。Torvalds氏は次のように説明した。 もうコーディングは全然やっていない。私がコードを書くのは、ほとんどがメールの中だ。
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
最近のPython-dev(2017-04) : DSAS開発者の部屋
バックナンバー: 3月号 2月号 1月号 NEWS (changelog) の作り方 Mercurial時代からNEWSファイル (changelog) の扱いは面倒だったのですが、Githubに移行したことでよりコンフリクトが起こりやすくなり面倒さに拍車がかかりました。 また、コンフリクトせずに間違った状態でマージされるというかなり致命的な事故も起こってしまっています。 (ワークフローが cherry-pick になったためにマージ時に履歴が考慮されなくなったのか、それともMercurialよりもGitの方がマージがバカなのか、詳細は把握してません。) それで、1つの大きなNEWSファイルにエントリを追記していく代わりに、1つのエントリだけを含む小さいファイルを追加していき、ツールでそれらのファイルからNEWSファイルを生成する仕組みへの移行が急務となり、ツールの選定のためにコンペが行わ
gitの良さがいまだに分からない - 負け犬プログラマーの歩み
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
6年間におけるGoのベストプラクティス | POSTD
（本稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です） 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments（本番環境でのベストプラクティス） 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、本番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい
PythonがGitHubに移行
現在Pythonの開発プロセス管理を担当しているBrett Cannon氏が，Pythonのcore workflowメーリングリストを通じて，GitHubへの移行を発表した。氏はInfoQのインタビューに応える中で，今回の決定に至った１年間に及ぶプロセスと，その中で検討された３つの提案について説明してくれた。 Pythonのリポジトリをホストするforge.python.orgの立ち上げ GitとGitHub，Phabricatorへの移行 GitとGitLabへの移行 この中から最終的にGitHubが選択されたのには，主に３つの要因があった。 GitHubとGitLabが機能面でほぼ同等であること。GitLabがオープンソースであることについては，それ自体を決め手だとは考えなかったと，Cannon氏は特に記している。 コアな開発者や外部協力者の間に，GitHubに精通している開発者が多
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
「GitHubでつくる、たのしい開発現場」YAPC:ASIA Tokyo2013 | Act as Professional
YAPC::ASIA Tokyo 2013（2日目）で「GitHubでつくる、たのしい開発現場」というトークをしてきました。 まず、利用した資料を公開します。 伝えたいことコードレビューを習慣化させたいのであれば、GitHubは最適なツールです。 コードレビューを習慣化させたい コードは書いた人以外の目にふれさせるべきと考えている人には特にオススメのツールです。 ですが、GitHubはあくまでツールです。このツールを利用することで、コードレビューの機会や良いコードを書くためのノウハウを学習する機会を生み出すことができます。 その結果、人やチームが行動を起こすことでチームが成長したり、結果として良いソフトウェアができていくはずです。 レビューをすると増えるコスト、減るコストレビューはすべきだけど、現在レビューを習慣化できていないチームにとって、新たにコードレビューをしていくのは単に時間的なコ
自分のいるブランチが他の人によってforce-pushされたとき，カレントブランチを削除せずに変更を取り込む - Qiita
自分のいるブランチが他の人によってforce-pushされたとき，カレントブランチを削除せずに変更を取り込むGit 例えばレビュー中に小さなバグを見付けたので，レビュイーにpush -fしてもらった後にその変更を手元に持ってくるにはどうすればよいか．歴史が変わっているのでgit pullはできない． 今までは以下のように別ブランチに移動&削除&再度ブランチ作成していた． # someone force-pushed to `topic` branch git co master git branch -D topic git fetch git co topic # creates `topic` branch from `origin/topic`
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
RhodeCode
RhodeCode 1.3.6 Released Posted on May 19th, 2012 | Read more RhodeCode 1.3.5 Released Posted on May 13th, 2012 | Read more RhodeCode 1.3.4 Released Posted on March 29th, 2012 | Read more RhodeCode 1.3.3 Released Posted on March 3rd, 2012 | Read more RhodeCode 1.3.2 Released Posted on February 28th, 2012 | Read more RhodeCode is a fast and powerful management tool for and GIT with a built in push/
githubを会社で導入してみて感じたこと - モノノフ日記
会社で利用するソースコードのバージョン管理システムをgithubに移行しつつあります。 gitは以前から個人で利用していたのでブランチ管理のメリットや気の利いたマージなどはもう知っていたのですが githubで同時に複数人で開発をする、という状況は初めてだったので感じたことを残しておきます。 導入 まず当然なのですが開発スピードは上がってます。 これはgithubというよりgitの分散リポジトリの仕組みが大きいです。svnでsvk使うと効率が良いのと同じことです。 そこで問題になるのが各開発者のリポジトリ間をどうやってマージさせていくのか、って所なんですが masterからリリース用のブランチを切ってそこにpull requestを投げて他の開発者に確認してもらってからマージする、という流れで今は運用しています。 投げられた側が確認してマージをコミットするので責任は一蓮托生としてます。 人
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DevOps の能力 | Cloud アーキテクチャ センター | Google Cloud
Cookpad iOS Release Flow
マジカルsvnとキュアgit