こんにちは、MF KESSAIでバックエンドのエンジニアのgarsueです。
2019年もあっという間すぎて戦慄しています。

今回はMF KESSAIでのGoのテストについて、ちょっと工夫してる点を書いてみようと思います。

並列テストによる問題

Go標準のテスト実行コマンドgo testはデフォルトでパッケージごとにテストを並列実行します。

通常は何もしなくてもテストが並列実行されてうれしいのですが、たまに困るケースがあります。

はじめまして、MF KESSAIでバックエンドエンジニアを担当している近江です。

今回は6月に行ったIKIOI(※)向上合宿で取り組んだ、entityからコード自動生成した話をしようと思います。 ※IKIOIとは、弊社のチーム開発力を示す指標です。（詳細はこちら）

なぜコード自動生成しようと思ったか？

MF KESSAI SRE（兼CTO）の @shinofara です。

いきなりですが、皆さんはどの様に秘密情報の管理と配布を行っていますか？

https://tech.mfkessai.co.jp/2017/07/1/ を公開した2017/07/31時点では、Google Kubernetes Engine(GKE)を中心としたシンプルなアーキテクチャでした。 当初はKubernetes Secretだけですので特に問題は無かったのですが、2年半と時間が立つことで目的に応じて利用するサービスも増えた事で Google App Engine(GAE/Se and GAE/Flex),Cloud Function(CF),Cloud Runなどのうえで、複数のアプリケーションが動く状態になってます。

今回の記事では、複数のアプリケーションが異なる環境で動く状態となり大変になってきた秘密情報管理と配布方法をふりかえりたいと思います。 そしてどういう管理配布方法に落ち着いたのかをご紹介させていただければと思っております。

MF KESSAI(以下MFK)でAPI開発を担当している@usumachiです。

MFKでは予てよりAPIを提供してきましたが、需要の変化やサービスの変化に合わせてVersion2(以下v2)の開発を進めています。 今回はv2のベータリリースにあたって僕のAPIv2への考えをお伝えしたいと思います。

Version2のドキュメントはこちらです。
MF KESSAI API v2

MF KESSAI開発合宿運営（CTO）の @shinofara です。

本日はマネーフォワードグループのエンジニアが集う開発合宿にMF KESSAI（以下MFK）も参加しています。 合宿は個人やチーム単位でテーマを持って開発するスタイルなので、MFKはこの場を借りて、第5回目の開発合宿を行うことにしました。

ですが今回の記事はちょうど3か月前の3月13日、14日に開催した開発合宿の内容をお話したいと思います。

今回の合宿について

過去には「技術研鑽」「場所を変えて仕事」「開発組織を今後どの様によりよくしていくか」などざっくりとしたテーマで開催してきましたが、今回は「開発のIKIOIを向上させ続ける」をテーマにしました。

そもそもIKIOIとはなにか

IKIOIとは弊社の1つのチームで自分たちのスループットを図る指標として生まれて、今では全チームが観測してるチーム開発力を示す指標となってます。