会社の本番環境をDocker(ECS)に置き換えるために準備したこと気づいたこと
エンジニアの@macs_6です。 このブログでは社内のAWS EC2上で運用しているアプリケーション群をECS移行したプロジェクトについて紹介します。 ローカルの開発環境をDockerした話は以前の記事(複数の rails プロジェクトが共存する開発環境を Docker 化した話を晒してみる)で西辻が紹介しているので、そちらを参照して下さい。 概要 プロジェクトを始める前に感じていた課題 目指す状態 ECSを選択する理由 設計 移行のために必要な作業 Digdagによるスケジューリングについて ECSを使って見て気づいたこと 今後やりたいこと プロジェクトを始める前に感じていた課題 ローカル・本番で再現性のある環境を簡単に作れるようにしたい 簡単にスケールできるようにしたい コストを抑えたい ECS移行プロジェクトを始める前にはこれらの3つの事に課題感を持っていました。 1.ローカル・本番
大きめプロジェクトにスクラムを適用する
こんにちは！Housmartの宮永です。 過去に弊社のスクラム開発について概要をご紹介(スタートアップのCTOになって2ヶ月で作った開発サイクル)させていただきました。 今回はより実践的な話を説明します。 以前紹介しました通り、カウル開発チームは1週間／スプリントと短めに取ってますが、 1週間じゃ収まらないようなサイズのプロジェクトの時はどう管理するの？って話になりますよね。 アジャイルの考え方では、要件を細分化することで1スプリント内に収め、 あくまでスプリント終了時には新機能をお客様に提供しないといけません。 しかし、モノによってはそうもいかないケースも有ります（と思ってます）。 （特に弊社は1週間スプリントですのでザラにあります） そういった複数スプリントを要する規模のプロジェクトに対してスクラムをどう適用させるか弊社の事例とともに紹介します。 プロジェクト背景 まずはプロジェクト背
スタートアップのための「お金と時間がかからない」ログ分析基盤
Housmart高松です。 「ログ分析基盤」というと、すでにかなり大きいサービスでの事例がSlideShareなどで共有されているのをよく目にしますが、 立ち上がったばかりのサービスに適用するには”too much”な内容となっていることが多いかと思います。 そこで今回は、まだユーザが少ないフェーズでも 「お金と時間をあまりかけずに」 導入できるログ分析基盤について、カウルでの事例をご紹介いたします。 小規模のサービスであってもログをしっかりと収集・分析してサービスの改善に役立てていくことは非常に大切なことです。 一方で、データ収集のためのJavascriptの開発やWebサーバの構築と管理、データストアやデータ処理基盤の選定や設定などに専属で人を割くことができないのもスタートアップの実情ではないでしょうか。 そこでカウルでは 安価に利用できるSaaSをいくつか組み合わせることで、簡単に始
スタートアップのCTOになって2ヶ月で作った開発サイクル
Housmartの宮永です！ 今回はカウル開発チームの開発サイクルを紹介させていただきます。 好ましい開発サイクルはサービスや企業、組織規模などに応じて 異なるものだと思いますので、このブログでもまずはチーム体制など 開発手法の採用背景となるところから説明いたします。 チーム体制、サービスについて カウル開発には５人のメンバーがいます。 エンジニア：３人 デザイナー：１人 プロダクトオーナー：１人 実作業ベースで5人の役割が決まっていますが、 サービスをどのように良くしていくかは皆で話し合って考えます。 サービス（カウル）はリリースされてからまだ２ヶ月弱で サービスローンチ後に想定外の運用業務が発生したり、ユーザからの改善要望も多く、 開発すべきこと（開発優先度）は日々変化しかなり流動的なものとなってます。 そのため、要件リストの優先度付けをこまめに行う必要があります。 開発サイクル 上記
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
