社内ツールをCakePHP4でつくりました

こんにちは。CTOの@itoshoです。

夏の甲子園が始まっていますね。ランチの時間はSPORTS BULLさんのアプリでバーチャル高校野球を観ています。 というわけで、フレッシュな高校球児に負けないようにフレッシュなCakePHP4で社内ツールをつくった話をしたいと思います。

なぜ、CakePHP4でつくったの？

現在、コネヒトのバックエンドのシステムはCakePHP3系が主流になっています。サービスが拡大していく中で今後他の言語やフレームワークを導入していく可能性はありますが、社内にPHP及びCakePHPのナレッジが蓄積されているので、当面CakePHPがコネヒトの技術スタックの主軸の一つであることは変わらないと考えています。そうすると、CakePHP3からCakePHP4へアップグレードしていくのは当然の流れですので、早めにCakePHP4を触っておきたいと思いました。

しかし、CakePHP4はまだstable版がリリースされておらず、4.0.0 beta1が最新のバージョンになります。*1ですので、もちろんプロダクション環境への導入はリスクがあります。しかし、社内ツールであればある程度そのリスクを許容することが出来ますし、むしろ、バグを踏めばCakePHPにコントリビュート出来るチャンスがあると考え、今回CakePHP4を採用することにしました。

どういうツールをつくったの？

この社内ツールについては、また別の機会に詳しく紹介したいと思いますがつくったものは以下のようなシンプルなwebアプリケーションです。

• 画面数: 12
• テーブル数: 5
• 機能のほとんどがシンプルなCRUD処理

隙間時間で開発していたので完成するまで1ヶ月弱くらいかかりましたが、ガッツリ時間を取ることが出来れば2〜3日で完成出来るボリュームかなと思います。

CakePHP4どう？

上述の通り、ほとんどの機能がbakeの自動生成してくれるコードに毛が生えたレベルで、ガッツリ使い倒したわけではありません。ですので、今後また別の印象を持つかもしれませんが、一つのwebアプリケーションをつくった印象としては「CakePHP3に慣れていれば、すんなり入っていける」と感じました。

そして、CakePHP4.0のロードマップを読むと、冒頭に以下のような記述があります。

CakePHP 4.0 will be a breaking change from 3.x. Unlike 3.0, 4.0 will primarily be a clean-up release. Instead of introducing large backwards incompatible changes, 4.0.0 will focus on removing all the deprecated features we've accumulated throughout the life of 3.x. Any method/feature emitting run-time warnings in 3.6 will be removed from 4.0. 4.0 will not add significant new features as the bulk of the release will be spent on cleanup efforts.

要約すると、4.0は2系から3系の時のような破壊的な変更をせず、非推奨機能の削除を中心に行い、後方互換性のない新機能は次の4.1で行うという方針になっています。つまり、4.0は4系にソフトランディングするためのリリースになっているので「すんなり入っていける」という感想を持つことが出来たというわけです。*2

その上で「おっ！」と思ったところを簡単に紹介します。

• テンプレートファイルがctpファイルからphpファイルになった
  • おそらく一番最初に気付くのがこの変更ではないでしょうか。拡張子が変わっただけかもしれませんが、PHPStorm使いとしては特別な設定をせずに、PHPファイルとして扱えるようになりました。
• デフォルトレイアウトにMilligramが採用された
  • Milligramは何度か使ったことがありますが、軽いし、デザイン性も高いし、カスタマイズもしやすいので個人的には嬉しい変更でした。
• リソースのルーティングのルールが一部変更になった
  • 複数の単語からなる、例えば TodoItemsController を作成した場合、これまでは todo_items というルーティングでしたが todo-items というルーティングになりました。なお、これまで通りアンダースコア形式にしたい場合はオプションで 'inflect' => 'underscore' を指定します。
• （bakeでコードの自動生成をすると）戻り値の型を宣言するようになった
  • 個人的にはこれが一番嬉しいなと思いました！別に元から書こうと思えば書けたのですが、これまでCakePHP本体が戻り値の型宣言をしていなかったので、それに追従する形でコネヒトではアプリケーションコード側も書いていなかったのですが、CakePHP4からは気にすることなく戻り値の型も宣言出来ることになりそうです。
• （bakeでコードの自動生成をすると）strictモードが指定されるようになった
  • これもよりタイプセーフなコードを実現するための一環ですね。strictモードの挙動については以前Qiitaにまとめた記事があるので、もし興味があれば併せてご覧ください。
• newEmptyEntity() メソッドの登場
  • これまで新しくEntityを作成する時は newEntity() メソッドを利用していたのですが、bakeで自動生成されるコードをみると今後は newEmptyEntity() メソッドを利用するほうがベターのようです。文字通り空のEntityを作成するメソッドなのですが newEmptyEntity() メソッドとの違いはEntity生成時にバリデーションを行うか行わないかの違いがあります（newEmptyEntity() メソッドはバリデーションを行わない）。

いますぐCakePHP4を使うには？

ここまで読んで、今すぐ私もCakePHP4を使ってみたい！と思ってくれた方は、以下のコマンドでプロジェクトの作成が可能です。ちなみに、CakePHP4からPHP7.2以上が必要条件になっていますのでご注意ください。

$ composer create-project --prefer-dist cakephp/app:4.x-dev app

冒頭に述べましたが、CakePHP3に慣れていれば、すんなり入っていけますし、上記に挙げたようなよりよい改善も含まれているのでstable版が出たら、プロダクションコードもなるべく早めにアップグレードしていきたい！という気持ちを新たにしました。また、これはCakePHP4に限った話ではないですが、やはりちょっとしたプロトタイプ的なwebアプリケーションをつくりたい時に非常に低コストで出来る点は改めて最高だなと思いました。*3

というわけで、今後もCakePHPと共に「人の生活になくてはならないもの」をつくっていくぞ〜！一緒につくってくれる仲間も絶賛大募集中です！

参考サイト

• 4.0 Roadmap · cakephp/cakephp Wiki · GitHub
• https://book.cakephp.org/4.0/en/appendices/4-0-migration-guide.html
• https://bakery.cakephp.org/2019/06/29/cakephp_400beta1_released.html
• 今からちょっとだけ先の未来、CakePHP4の話 〜Upcoming CakePHP Roadmap & Releases〜 - コネヒト開発者ブログ

*1:2019年8月13日現在

*2:言うは易く行うは難しだと思うので、これを実現してくれているCakePHPコアチームの皆さんは本当に凄いと思います。

*3:実は当初Go×ReactでSPAっぽくつくろうと思ったのですが、つくりたいものに対して若干オーバーエンジニアリング感があったので、辞めたという経緯があります。

iOS版ママリの開発環境をXcode10.2/Swift5にアップデートしました

はじめまして、2019年5月に入社したiOSアプリエンジニアのあぼ(@suxisuxido)です。入社後は『既存チーム』と呼ばれる、ママリアプリの既存機能の改良などを行うチームで、iOS側の開発を担当しています。

コネヒトでは先日、iOSの開発環境をXcode10.1/Swift4.2から、Xcode10.2/Swift5にアップデートしました。今回はそのことについて書こうと思います。

ライブラリのAPI変更への対応

各種ライブラリのバージョンアップに伴い、コードの変更が必要です。ワーニング解消も含めると、RxSwiftまわりの変更が一番多かったです。

RxSwift.VariableをRxRelay.BehaviorRelayに変更

便利なVariableはRxSwift4.0.0-rc.0からdeprecatedになっています。今回のタイミングで、同様の使い方ができるRxRelayのBehaviorRelayに変更しました。

- import RxSwift
+ import RxRelay

- let isConnecting = Variable(false)
+ let isConnecting = BehaviorRelay(value: false)

- isConnecting.value = true
+ isConnecting.accept(true)

https://github.com/ReactiveX/RxSwift/releases/tag/4.0.0-rc.0

throttleやdelayオペレーターの引数をTimeInterval からDispatchTimeIntervalに変更

こちらはRxSwift5からdeprecatedになっています。もともとDouble型で計算した結果を使っていた場合はロジックの変更が必要ですね。

- throttle(1.2)
+ throttle(.milliseconds(1200))

- throttle(3)
+ throttle(.seconds(3))

https://github.com/ReactiveX/RxSwift/releases/tag/5.0.0

Swift5の新機能Raw stringsの利用

Swift5の機能のひとつ、Raw stringsを使って、正規表現から"\"のエスケープを削除しました。

- NSRegularExpression(pattern: "^(\\d+)歳")
+ NSRegularExpression(pattern: #"^(\d+)歳"#)

正規表現はどうしてもバックスラッシュが多くなりがちなので、積極的にRaw stringsを使ってスマートに書いていきたいですね！

https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md

Xcode10.2ではiOS12.2のデバッグが可能に

じつはこのとき、いくつかの検証端末が意図せずiOS12.2に上がってしまっていたため、Xcode10.1のままではデバッグができず不便でした...。

Xcode10.2にあげたことによってiOS12.2のデバッグが可能になり、弊iOSチームは救われました(´・∀・｀)

https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_release_notes

モンキーテストの実施

一通り対応が終わったら、既存チームでモンキーテストを行いました。

Xcode10.2/Swift5対応がアプリへもたらす影響範囲は大きく、かつ私自身はまだママリアプリの機能について知識が少なくデグレにも気づきづらいので、知識ある人に触ってもらって怪しいところを事前に拾うのが狙いです。

結果的にこのモンキーテストで1つデグレが見つかったので、やっておいてよかったな〜と思っています。

モンキーテストご協力のお願いのようす

おわりに

影響範囲が大きく、気を張って行う必要があるという意味ではそこそこ大変でした。このほかにも、単体テストで保証しやすいのに実際にはテストが書かれていなかった箇所に、単体テストを追加したりしました。

こういう開発環境アップデートは遅くなればなるほどあとからやるのが大変になったりしますし、そのあいだ新機能が使えないままなので、タイミングをみて今回実施できてほんとによかったです！

CakePHP2用のMaster/Replica接続管理プラグインをOSS化しました

こんにちは、サーバーサイドやっております 金城 (@o0h_)です。
「腸よ鼻よ」を応援しています。人間ってたくましい。

腸よ鼻よ(1)

webでも読めます https://ganma.jp/chohana

さて、掲題のとおりですが、以前にママリのマスプロモーションを実施した際の負荷対策として作成した機構をプラグインとして公開しました。

packagist.org

MySQL用のデータソースで、1つのモデル*1に対して複数のデータベース接続を提供する機構です。 例えば「参照しか走らないリクエストは参照用DBに接続して、更新系はマスターDBに接続する」といったような使い方を想定しています。

簡単に利用方法を紹介します。

1. Pluginを配置する
2. 「複数の接続先」をconfig(database.php)に書き込む
3. (Controller等で)必要に応じて接続先情報を変更するメソッドを実行する

Pluginの配置

Composerによるinstallに対応しています。
これを、plugins もしくは app/Plugin に配置してください。 詳細はCookBookを参考にしてください

https://book.cakephp.org/2.0/ja/plugins/how-to-install-plugins.html#composer また、Pluginを配置した後、プラグインをloadするのをお忘れなく。

接続情報の設定

DATABASE_CONFIGの設定を変更します。 例として、書き込み対応の「master」参照専用の「secondary」という、2つのDB接続を利用するケースを想定します。

• masterは host:master-db-host; port: 3306; login: root; pass: password
• secondaryは host:secondary-db-host; port: 3306; login: root; pass: password
• DB名はどちらも my_app
• デフォルトでは secondary に接続を向ける

その際には、以下のような記述になります。

<?php
class DATABASE_CONFIG {
    public $default = array(
        'datasource' => 'MasterReplica.Database/MasterReplicaMysql',
        'connection_role' => 'secondary',
        'connections' => array(
            '_common_' => array(
                'login' => 'root',
                'pass' => 'password',
                'database' => 'my_app',
            ),
            'master' => array(
                'host' => 'master-db-host',
            ),
            'secondary' => array(
                'host' => 'secondary-db-host',
            ),
        ),
    );
}

• まず、datasourceを MasterReplica.Database/MasterReplicaMysql に変更します。
  ※ app/Plugin/MasterReplica にプラグインを配置している想定です
• connection_role に、「デフォルトでどこに接続させるか」という名前を指定します
• connections という配列で、「接続名 = key」として、それぞれの接続情報を設定します
  • _common_ は特別なkeyで、全接続先に対する共通設定値をもたせます。今回は login, pass, databaseが共通です
  • master, secondaryに対して「個別に設定したい情報」をもたせます。この内容が、 _common_ と結合されて利用されます
  • なお、接続名(master, secondary)には任意の名前を利用することが可能です

これで接続情報のセットアップができました。

実際に接続先情報を変更する

Datasource経由で、「接続先変更」メソッドを実行することで、接続先の変更ができます。 switchConnectionRole($接続先名) を利用してください。

例えば、以下のコードは実際にプラグインのテストコードとして利用しているスニペットをベースにしたものです。 cf: MasterReplicaMysqlIntegrationTest.php#L78-L95

<?php

$conn = $this->Post->getDataSource();

// masterに向けて書き込みを行う
$conn->switchConnectionRole('master');
$newData = [
    'user_id' => 10,
    'title' => 'Lorem ipsum dolor sit amet',
    'content' => 'Lorem ipsum dolor sit amet',
];
$this->Post->save($newData);

// secondaryに向ける
$conn->switchConnectionRole('replica');

$savedData = $this->Post->read();

実用例①

「ログインしているユーザーはmasterに向ける(データの更新が可能)」という場合は、AppController::beforeFilter()で操作するというのも手です。

<?php

// ログイン処理後
$role = AuthComponent::user() ? 'master' : 'replica';
MasterReplicaMysql::setDefaultConnectionRole($role);

実用例②

IntegrationTest実行時に副作用として「接続先が切り替わったまま」になるので注意してください。
具体的に言うと、「参照DBに向けたままだとtableの作成やtruncateに失敗する」ので、setUp()/tearDown()ができません。

ControllerTestCaseを継承したサブクラスを用意し、 testAction() メソッドを上書きすることで対応が可能です。

<?php

protected function _testAction($url, $options = []) {
        $sourceList = ConnectionManager::sourceList();
        foreach ($sourceList as $source) {
            $obj = ConnectionManager::getDataSource($source);
            if (get_class($obj) !== 'MasterReplicaMysql') {
                continue;
            }
            if (in_array($obj, $this->masterReplicaSources, true)) {
                continue;
            }
            $this->masterReplicaSources[] = $obj;
            // DB再接続時にテーブル情報のキャッシュが副作用をもたらすケースがあるので
            // キャッシュ利用フラグを折っておく
            $obj->cacheSources = false;
        }

        try {
            $result = parent::_testAction($url, $options);
        } finally {
            // _testAction内での副作用を消すため、
            // 初期接続先をmasterにした上でDB接続を初期化する
            if ($this->masterReplicaSources) {
                MasterReplicaMysql::setDefaultConnectionRole('master');
                foreach ($this->masterReplicaSources as $obj) {
                    $obj->switchConnectionRole('master');
                }
            }
        }

        return $result;
}

CakePHP2のプラグイン作成にあたって

FriendsOfCake/travis が便利で、活用させていただきました。

github.com 一部、(Cake3がメインストリームということで・・)工夫する必要がある箇所もありますが、それでも.travis.ymlをかなり簡潔に保てて利便性が高いと思います。

詳しい内容は 実際のYAMLファイルを御覧ください。

おわり！

かなり足早にではありますが、簡単なご紹介をさせていただきました。
PRやIssueをお待ちしております！！！！💪💪💪 簡単な質問等であれば、お気軽にTwitterでリプ飛ばしてください。

コネヒトではCakePHP3も同様の機構を利用しており、こちらも現在OSS化作業を進めているところです。
近日中に披露できれば、と思います。

*1:databaseのconnection定義

監視の民主化に向けて「モニタリングツール多くない？」という話をしました

こんにちは、サーバーサイドやっております 金城 (@o0h_)です。
最近の癒やしは「幸せカナコの殺し屋生活」です。仕事でも趣味でも何でもいいと思いますが、「私は生きているんだな！」という気持ちを抱えて育んでいくのが大事だな、と改めて気付かされます。

sai-zen-sen.jp

Tl;DR

1. モニタリングツール増えがち問題; システムが複雑なんだ、しゃーない
2. 「多すぎるツール」が監視ビギナーのハードルを上げていないかな。下げたい・・・！
3. 「なぜ複数のツールが必要なのか」の肌感を共有したい
4. まずは「最初の1つ目」のツールを習得して、次第に使えるツールを増やしていくのが良いのではないか

GreenkeeperからDependabotに移行しました

こんにちは、安達 (@dachi_023) です。ちょうど1年前くらいにGreenkeeperを入れた話を書いたんですが、今回はそこから更にDependabotに移行した話をします。

導入にあたって

コネヒトではこれまでGreenkeeperを使って複数のリポジトリでパッケージのバージョン管理をしていましたが、それらのすべてを廃止してDependabotに移行しました。

なぜDependabotを選んだのか

GitHub傘下になったよの記事を読んで気になったのでお試しで使いはじめたのがきっかけで、Greenkeeperを使っていた時に物足りないなーと感じていた部分がDependabotでは解消されていて、乗り換えたほうが効率いいなと思ったのでGreenkeeperを解約してすべてDependabotにしました。

Dependabotの良いところ

• 複数言語をサポートしているため、言語ごとにツールを選定する必要がない
• 設定ファイルは必須ではなく、GUIの設定だけでも動作する
• GitHubのPull Requestに対してAssignee, Label, Reviewerが設定できる
• セキュリティアップデートは即時投げてくれる

複数言語のサポート

言語ごとに良さそうなツールを探してきて権限を渡して設定ファイルを作ってリポジトリに置いておく、みたいなのはしなくて良くなりそうかなと思ってます。あのツールじゃないと出来ないことがあるんだ、とかそういうのがなければ全部Dependabotに寄せておけば管理も楽で良さそうです。

設定ファイルは不要

設定ファイルは書けますが、設定画面が提供されているので必須ではないです。ただし、各パッケージでバージョン指定をしたい場合はGUIでは指定できないようです。

Assignee, Label, Reviewer

https://github.com/pulls/assignedを見て自分がボールを持っているレビューがあるかを確認しているのでAssigneeを設定できる機能がついているのが個人的にはとても嬉しいです。

セキュリティアップデート

セキュリティパッチを含むバージョンが公開されたら随時飛んでくる、というセキュリティ意識が高まる素敵な機能です。セキュリティアップデートだけPR作ってくれる、とかも可能です。

所感

機能自体には満足していますが、週ごとや月ごとにまとめて飛んでくるようにしてるとCIのジョブキューが詰まるのでそこだけ注意が必要かもなと思いました。

リンク

• Dependabot
• Dependabot Preview · GitHub Marketplace

CodeBuildを使ったECSへのコンテナデプロイ

こんにちは。インフラエンジニアの永井(shnagai)です。

今回は、CodeBuildでのECSデプロイについて書いてみました。 普段、TravisCIを使ってメインサービスのECSのデプロイを行っているのですが、新規開発するにあたりCodeBuildを使ったECSのデプロイを組んでみたのでその内容をまとめています。

内容はざっくり下記4項目について書いてます。

• CodeBuildのみで行うECSへのコンテナデプロイの構成図
• 他のCIサービスと比べた時のCodeBuildの良さ
• CodeBuildの設定でハマった点
• デプロイフロー

CodeBuildのみで行うECSへのコンテナデプロイの構成図

CodePipelineを使ったECSへのデプロイをする選択肢もあるのですが、これだと運用フローに大きく変更が入るので今回は、現在使っているecs-deploy を使ったECSデプロイを移植する形にしました。 全体のデプロイフローとしては下記のような形になっています

他のCIサービスと比べた時のCodeBuildの良さ

個人的に感じた、CodeBuildによるコンテナビルドの良さについてまとめてみました。

プロジェクトの並列度を考えなくて良い

一般的なCIサービスだと契約プランによって並列度には制限あると思います。 従量課金で何プロジェクトでも並列で動かすことが出来るのはCodeBuildならではだと思います！

Dockerイメージビルド時のローカルキャッシュが設定一つで有効化出来る

コンテナをフルビルドするするとめちゃくちゃ遅いですよね。。 もちろんCIサービスでもレイヤキャッシュをバックアップしてごにょごにょすることでキャッシュすることは出来るのですが、CodeBuildだと設定一つですごく簡単に、DockerBuild時のキャッシュ設定で出来るます。 これは、革命的かと思います。

プロジェクトのアーティファクトから下記設定をすることで、Dockerのレイヤキャッシュが有効になります。

項目	値
キャッシュタイプ	LOCAL
ローカルキャッシュオプション	LOCAL_DOCKER_LAYER_CACHE

※ただ、ローカルキャッシュというだけあって、ビルドによりキャッシュが効いたり効かなかったりまちまちだなという印象です。裏側のアーキテクチャがわからないですが、これはビルドを多数繰り返すことで複数ホストにキャッシュが出来て解決されるものなのか、また別の理由なのかは運用しながら探っていければと思っています。

参考までに、検証時に試したキャッシュ利用有無でのビルド速度の違いです。

DockerのBUILDKITも使える

Dockerビルド高速化における切り札とも言える、BUILDKIT もランタイムのDockerが18.06以上なのでサポートされています。 ローカルのビルドはBUILDKIT前提なのだけど、CIサービスが対応してないからデプロイにかかるビルドは遅いみたいな悩みともおさらば出来ます！

buildspec.ymlに下記を記述することで利用可能になります。

DOCKER_BUILDKIT: "1"

IAM Roleで権限をコントロール出来るので、鍵の管理が不要に

IAM Roleでプロジェクト毎に必要な権限を管理出来ます。 CIのプロジェクト毎に鍵の登録をするような運用がなくなるのがgoodだなと思います。

CloudWatchEventsのトリガにCodeBuildのイベントを指定出来るので通知も簡単に書ける

TravisCIでは、エラーハンドリングをしながらSlackを呼び出すことで通知を実装していました。

CodeBuildだと、下記のようなカスタムイベントパターンを指定することで、CodeBuildのステータスをトリガにLambdaを呼び出せます。 プロジェクトの状態検知はこちらに寄せることが出来るので、簡単に通知をすることが出来ます。

このイベントを受け取りLambdaをキックすることで、Slackに飛ばす運用をしています。

{
  "source": [
    "aws.codebuild"
  ],
  "detail-type": [
    "CodeBuild Build State Change"
  ],
  "detail": {
    "build-status": [
      "FAILED",
      "IN_PROGRESS",
      "SUCCEEDED"
    ],
    "project-name": [
      "トリガに使いたいproject-name",
    ]
  }
}

イメージ

CodeBuildの設定でハマった点

CodeBuildは、s3でホストしている静的コンテンツ配信サイトの自動更新には使っていたのですが、久々に触ったら下記の点が変わっていたので少しハマりしました。

ランタイムの指定方法が変わっていた

これまでだと、CodeBuildのランタイム環境は、例えばjsのビルドに使う環境だとaws/codebuild/nodejs:10.1.0 というようにプロジェクト側に指定する形だったのですが、今回プロジェクトを作る中で、 aws/codebuild/standard:2.0-1.10.0 といったような standard イメージしか選択出来ないようになっていました。

トラブルシューティングにあるくらいメジャーなエラーだったのですが、、、下記サンプルのように、buildspec.ymlの中でランタイムを指定することに気づかずハマりました。

Troubleshooting CodeBuild - AWS CodeBuild

phases:
  install:
    runtime-versions:
      docker: 18
  build:
    commands:
      - echo docker tag replace started
      - ...

プロジェクトの発火条件になるGitHubのイベント設定

CodeBuildはイベントタイプ+細かな条件を指定してプロジェクトを発火出来るのですが、下記の設定にたどりつくまで色々と試行錯誤しました。

これはCodePipelineだとブランチ指定した設定しか出来なかったのを自分の中で引きずっていたというのが大きいのですが、CodeBuildではもう少し細かい発火条件が出来るのを知るまでに少し時間がかかりました。

• masterへのpush時にプロジェクトを発火させたい場合は下記のような設定をします。

• tag push時にプロジェクトを発火させたい場合は下記のような設定をします。

デプロイフロー

参考までに現在のこのプロジェクトのデプロイフローは下記のようになっています。

① GithubのPRベースで開発

② masterマージ時に、code buildの[StgProject]が発火して下記要領でステージングへのデプロイを実施

• Dockerイメージのビルド
• ECRの該当リポジトリに対して、latest というタグでpush
• ecs-deploy(shellで書かれたツール)により、対象サービスの更新を行う

③ ステージング環境にてデプロイした変更に問題がないことを確認

④ 本番デプロイするために現在のコードに対してtagを打つ

⑤githubのtag push時に、code buildの[prdProject]が発火して下記要領で本番へのデプロイを実施

• ECRにあるイメージをタグ名リプレイスしてコピー
  • latest→release, release→release-1gen,release-1gen→release-2gen
  • aws cliのecr batch-get-image, ecr put-image を利用
• ecs-deploy(shellで書かれたツール)により、対象サービスの更新を行う

⑥ 本番にて動作確認のテストを行う

⑦ やばいとなった時は、 ecs-emergency-rollback.sh にて緊急ロールバック(release-1genイメージ使ったロールバック)を行う

コネヒトでは一緒に成長中のサービスを支えるために働く仲間を探しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

AWSやDockerを駆使してサービスの信頼性を向上させるエンジニア募集 - コネヒト株式会社のインフラエンジニア中途の求人 - Wantedly

PHPフレームワークのバージョンアップを支える技術

GWいかがでしたでしょうか？
私はひたすらに「何もしないぞ！」を徹底した結果、漫画を読んで「色々な世界を旅して」「色々な出会いと別れを繰り返して」過ごしました。

その中でも、「子供はわかってあげない」を久しぶりに読み返し、

人は教わったことなら教えられるんだよ

からの

僕は誰にも教わってないんだ。・・・だから教えるのが難しいの当たり前なんだなって思って・・・少し楽になったかな

というくだりにグッと来ました。
「教えられることがある」や「教えてくれる」というのは、それだけで尊いものだな〜というリスペクトを忘れないようにしようと思うのと同時に、自分や他人の「持てるもの・持てないものを見極めて、許したり奮ったりしてけたらな」とも思いました。
なんにせよ、他人に教えられる人はすごい！🎉

子供はわかってあげない(上) (モーニング KC)

さて、こんにちは、サーバーサイドやっております 金城 (@o0h_)です。

今回は、「PHPフレームワークのマイナーアップデートをしようとしたら少し大変だったので、工夫したこと・やったこと」のお話をします。

TL;DR

• CIの活用 / (ユニット)テストを日頃から充実させておく
• Migration GuideやPRに目を通して、影響範囲を予想する。対応イメージを考える
• ツールによる自動対応が可能なモノは積極的に活用する
• 「どっかで何かが起きた」ときのgit-bisect
• リグレッションテストの計画と実施