共有の実行基盤と、拡張できるバックエンド
バックエンドはCloud RunとCloud SQLで構築します。複数のクライアントやブランドを扱う場合は、最初からマルチテナント構成を設計し、ストレージと計算を分離します。サイトごとに常時稼働のサービスを用意する必要はありません。
クラウド / アーキテクチャ
公開でき、状態が見え、引き継げるクラウド構成。
GCPを中心に、スムーズにデプロイでき、公開後も状態が見え、次に引き継ぐ人にも分かりやすいサービスを設計します。
プロジェクトについて話しましょうこんな課題はありませんか
システムが増えると、悩みは「どう公開するか」から「どう運用するか」に移ります。サイトを1つずつ手でアップロードし、ドメインや証明書もサイトごとに設定する。何か起きたとき、前のバージョンに戻せるか誰も確信を持てない。クラウド構成に必要なのは、障害時に何をすればよいか分かることと、次に引き継ぐ人が読み解けることです。
私たちの進め方
検証できるフローとしてのデプロイ
アップロード後にまず検査し、バージョンを作成してから公開を切り替えます。失敗した場合は切り替えの前で止まり、中途半端な状態が本番に残りません。
ドメイン・証明書・CDNを自動で処理
Cloudflare DNS、SSL、WAF、CI/CDを1つのパイプラインに組み込み、サイトごとの手作業をなくします。
すべてのバージョンを保存し、いつでも戻せる
デプロイのたびに独立したバージョンが作られます。問題が起きたら、再アップロードなしで1つ前のバージョンに切り替えられます。
お渡しするもの
- 複数サイトのホスティング基盤
- 拡張可能なバックエンド
- 既存システムの移行と引き継ぎ
- CI/CDパイプラインとデプロイ手順書
ご一緒する流れ
まずはお話から
30分ほど今の状況を伺い、課題、時期、次に進むべき一歩を一緒に整理します。
範囲とお見積もり
作業範囲、納品物、スケジュール、金額を書面でお渡しします。後から追加費用につながりやすい曖昧な項目は残しません。
開発
確認できる進捗とリスクを毎週共有し、プロジェクトの現在地がいつでも分かるようにします。
納品と引き継ぎ
コード、ドキュメント、デプロイ権限、運用知識をお渡しし、引き継ぎの条件も明確にします。
こんな方に
- サイトやサービスが増え続け、デプロイが重くなってきたチーム
- 既存システムをクラウドへ移す、または構成を見直したいチーム
- 公開後の運用、ドキュメント、明確な引き継ぎを重視するチーム