Feature Toggleを用いたRailsアプリの継続的なリリースと要注意事項 - メドピア開発者ブログ
はじめに 皆様こんにちは、サーバーサイドエンジニアの草分です。 突然ですが、開発者の皆様、実装したソースコードはこまめにリリースしていますか？ 「大きい機能なので開発に時間がかかる」「障害が起きないよう念入りにテストする必要がある」などの理由で、Featureブランチのままコミットグラフが伸びに伸びたりしていませんか？ 大きな機能を作ること自体は悪いことではありませんが、大きすぎるFeatureブランチは、本流ブランチとの挙動の乖離やコードの衝突が発生しやすく、レビューやマージに多大な苦労を伴います。 この記事では、この問題の解決策の1つとなる「Feature Toggle」を、Ruby on Railsにおける実装方法と共にご紹介します。 Feature Toggle自体は開発手法の一種であるため、言語/フレームワークを問わず広く活用されています。 Feature Toggleとは 「機
「職能横断チーム」の実践におけるアンチパターンと対策 - yigarashiのブログ
近年のアジャイルムーブメントにおいて「職能横断チーム」は当たり前の概念になっています。ユーザーに価値を届けるのに必要なあらゆる機能をチームが備え自律的にコントロールすることで、リードタイムを短縮するとともに、イノベーションが起こりやすい環境を作ることができます。しかしながら、7〜8人を超える大きめの集団になってくると、開発の効率を著しく下げるアンチパターンを踏んでしまうことがあります。 「職能横断チーム」の実践におけるアンチパターン そのアンチパターンとは「いつも全員一緒」です。バックエンドエンジニアだろうとアプリエンジニアだろうと、デザイナーだろうとプランナーだろうと関係なくとにかく全員です。サイロ化のカウンターとしての「職能横断チーム」に囚われ過ぎてしまって、チーム内に部分集合を作ることを極端に避けてしまっている状態です。その結果、10人もいる会を開いて細かい相談で時間が伸びたり、そも
■ - hitode909の日記
アドバイスを求める相手というと、家族とかパートナーみたいな、対等なこともあるけど、上司や先輩、チームリーダーなど、目上？の人が多い気がする。 その相手が、なぜリーダーになっているかというと、突っ走って成功しているから、だったり、なぜ先輩なのかというとその年齢まで生き延びているから、だったりと、リーダーになる前に脱落した者や、先輩の年齢になる前にこの世を去った者たちがいるはず。 そういう生き延びた人たちにアドバイスを求めると、「そういう場合は、強気でバーンと行けばなんとかなったよ」とか、「そういう場合は自分の場合は、腕力でねじ伏せたらなんとかなりました」とか、生き延びた結果のアドバイスが出てきがちで、それを後輩とか、チームメンバーとかに真似してもらおうとすると、なかなか難しいものがあるかもしれない。 アドバイスの生存者バイアス、というとよく聞くけど、アラートを上げるかどうかと、問題に思うかど
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
