You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ&エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
最近以下のような記事で個人開発のコストの話をよく見かけて、ちょうど自分も個人サービスをコストカットのためにVPSからほぼ無料なスタックに移行していたので構成とかを書いてみる。 前提としてはこんな感じ。 仲間内で使ってるだけのWebアプリケーション。月イチくらいしか使わない 技術スタックは技術的な実験とか学習を兼ねているので多少オーバースペックになるのはいい お金はなるべくかけたくない 移行前のスタック フロントエンドはNuxt.js、Netlify バックエンドはRailsでgRPC、envoyを噛ませてフロントエンドからはgRPC-Webで呼んでる VPS上にバックエンドのアプリケーションとDB(postgres)を動かしてる バックエンドは普通のRailsアプリにしてHerokuにするのが一番楽でお金もかからないんだけど、gRPC-Webを試してみたくて、そうするとproxyが必要にな
この記事は LAPRAS Advent Calendar 2019 の18日目です. 会社でWebサービスを開発していると,検証したりレビューしたりするときに専用の環境が欲しくなる.それは開発しているブランチごとに独立した環境であって欲しいし,なんなら本番っぽいデータが入っているとなお良い. そしてエンジニアだけでなくデザイナーやPOもアクセスできて欲しい.俺のローカル環境を立ち上げればいい?最初は確かにそうなんだけれど,開発メンバーが増えてきたときに,全員がそれをやらなきゃいけないというのはコストだ.レビューのたびにそれをやるとなると,かなりのコストだ. そいうわけで社内に検証環境を立ち上げるyadockeriというプロダクトを前職で作っていたんだけど,今の職場でも作りたくなってしまったのであった(3年ぶり2回目). kubernetesで,helmで 本番環境は全部kubernetes
YAPC::Asiaのスライドで予告していた通り、実際に弊社のいくつかのサービスで使っている my.cnf を公開しました。 github: https://github.com/kazeburo/mysetup/tree/master/mysql 今回、公開した理由はMySQl Beginners Talksの発表の中でも触れている通りです。MySQLのソースコード中に含まれるサンプルのmy.cnfが最近のサーバハードウェアや運用に合わなくなって来ているという状況で、自分の設定にイマイチ自信が持てていない人は少なくないはず。そこで各社秘伝のタレ的な my.cnf をOpen & Shareすることで、モダンなmy.cnfを作り上げる事ができるんじゃないかという考えの下、今回 github にて公開しました。 ファイルは4つあり、それぞれ MySQL 4.0、5.1、5.5、そしてテスト中
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く