MisocaのCI構成まとめ - 弥生開発者ブログ
こんにちは。4月からMisocaにjoinしました、tkykです。京都市内からリモートで働いています。盆地特有のねっとりとした暑さをやり過ごしつつコードを書いている今日この頃です。 さて、今回はMisocaのCI（Continuous Integration）環境がどうなっているか、その全体像を紹介したいと思います。 そもそもCIの目的とは？ ソースコードの一部に対する変更が、アプリケーション全体の動作を壊してしまっていないか、常時チェックするのが目的です。 そのために何をしているか CI専用のサーバに、変更点を含むソースコード全体をチェックアウトして、依存ライブラリのインストールと必要な前処理を行い、すべてのテストを実行します。 すべてのテストがエラーなくpassしたことをもって、CIが通ったとしています。 Gitを使った開発フローとの統合 MisocaはGitHub上で開発を行なってい
Slackを使いこなすための設定とMisocaにおけるSlackしぐさ - 弥生開発者ブログ
はじめに MisocaチームのRKTMです。 この投稿は、ときどきナガノという、 長野県庁の企画を利用して、長野県松本市のコワーキングスペースにて書いています。 Misocaではリモートワークができるため、金曜日に旅先へ移動して仕事->土日をフルに観光に使えます。 松本からは冠雪した北アルプスを眺めるられるかなーと思っていましたが、ちょっと雲がありますね。あの雲の向こうの雪山に心惹かれています。 SlackはMisocaチームに欠かせないツール MisocaチームではSlackをどうやって使っているか、という記事は過去に公開しています。 tech.misoca.jp Misocaではリモートワークを推奨しているため、松江オフィス、岐阜など、名古屋オフィス以外でメンバーが活動しています。 www.wantedly.com リモートの人がいることもあり基本的なコミュニケーションはSlackで行
レビュー依頼前のコミット整理方法 - 弥生開発者ブログ
Misoca開発チームのmzpです。 新しいMisocaステッカーが完成したので、いろいろな場所で配りはじめました。 今日は、Misoca内でレビュー依頼をする前にやっているコミットの整理について紹介しようと思います。 Misocaの開発の話ですので、GitHubのpull requestベースでのレビューが前提です。 要約 pull requestをレビューしやすくするために、コミットを整理しよう。 方針 最終的な結果だけを残し、途中の試行錯誤の跡を消す 無関係の内容は別のコミットにする 具体的な作戦 自動生成と非自動生成のものは分ける scaffoldで生成されたものや Gemfile.lock 等の自動で更新されるものは、特にレビューする必要はありません。 そのため、それ以外の手で書いた変更とは別のコミットとは別にしておくとよいです。 試行錯誤の跡を消す PR内で発生したバグの修正コ
Misoca開発で日々使う知識とその情報ソースまとめ - 弥生開発者ブログ
9月末に涸沢の紅葉を堪能してきた@RKTMです。ちょっとピークが過ぎていた&日差しが弱かったのですが、パノラマコースからのパノラマに大興奮でした！ 開発メンバーの知識のばらつき この記事を書くことになったきっかけはあるPull Requestでのレビュー指摘から。 レビューア「このXxxControllerのインスタンス変数@documentって、view側で使われていないし、ローカル変数documentにしたほうが良いのでは」 実装者「なるほどー。あ、このメソッド内のlambda式でdocumentという名前を使っているので、区別するために@documentのままにしておきます」 レビューア「えっ。変数のスコープは必要ない限り狭くすべきだよ。スコープが広いと、意図しないところから参照されたり、値が変更されたりするので、変数名を変えてでもスコープは狭くしたほうが良いよ」 上記は、実装面での
Misocaのプルリクエストの運用について - 弥生開発者ブログ
こんにちは。 開発チームのウォーボーイズことめろたん(@renyamizuno_)です。 みんな！V8讃えてるぅ！？ はい。 今回は前回まで続けていた便利なGem紹介をネタ切れのため一旦置いておいて、 Misocaのプルリクエストの運用について書きたいと思います！ Descriptionのテンプレート 弊社ではプルリクエストのDescriptionを書くときのためのテンプレートが存在しています。 CONTRIBUTING.mdに、 ## 関連文書 * ＊＊＊＊ * 関連Pull request: xxxx ## 変更点概要 (どう変わるのかを簡潔に。 複数の変更を行なっているならPRを分割すること) ## 注意・伝達事項 * 今後の実装において注意すべき点や、使うと便利な点。 * 見てほしい箇所や、整合性が気になる箇所について。 * レビュー時の観点について:＊＊＊＊ ## このPull
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
