[B! circleci][aws] manabouのブックマーク

GitHub Actions + CircleCI + AWS CodeDeployによるCI/CD環境にインフラを移行した話 - SMARTCAMP Engineer Blog

スマートキャンプ、エンジニアの入山です。前回のブログで、弊社プロダクトのインフラをEC2基盤からECS/Fargate基盤へ移行した話を紹介しました。 tech.smartcamp.co.jp 上記プロジェクトは大規模なインフラの刷新だったこともあり、CI/CDについても従来の仕組みからECS/Fargateの構成に合わせて変更しています。 CI/CDは、安定したプロダクト開発には必須且つ長期に渡って継続的に利用するものなので、いかにストレス少なく効率的に出来るかが重要だと考えています。また、CI/CDは一度構築してしまうと放置されがちですが、日々の開発チーム全体の生産性にも大きな影響を与えるため、こういった数少ない再構築のタイミングではコストを掛ける価値があるのではないでしょうか。今回は、弊社のインフラ移行時に実施したCI/CDの改善について紹介したいと思います。従来のCI/CD

manabou 2021/08/25

リンク

CircleCI 2.0アップグレードをあきらめてCodePipelineでGitHub→S3静的ホスティングのCD環境を作った話 | DevelopersIO

ベルリンのしがひです。クラスメソッドヨーロッパのウェブサイトはS3のスタティックホスティングとCloudFrontを使ったサーバーレス・超低コストな構成になっているのですが、サイトの編集管理ワークフローとして、GitHubとCircleCIを使っていました。 CircleCIはパフォーマンスが大幅に強化されたバージョン2.0が現行で、1.0は2018年8月31日でディスコンされるというアナウンスが昨年のはじめにありました。1.0 --> 2.0のアップグレードは何かボタンを押せばできるというたぐいのものではなく、yamlの書き換えとソース配置の再検討が必要になる大仕事で、見なかったことにしていたら9月になっていました。早くアップグレードしなさいという圧を感じます。しかしこう言われると、動いているものを変えろというわりには成果が少なく、もっとなんかできるんじゃないか、と、このメッセージを書

manabou 2019/04/16

リンク

Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note

TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した背景今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすいインフラの実構成がバージョン管理出来ていないちなみにRoute53に関してはroadworkerを用いてコードで管理済

manabou 2015/02/19

リンク

Wercker + Vagrant + AWS + serverspecでChefのレシピをCIする

[2014-01-09-1] からmasutaka.netのCIを開始したが、残念ながら masutaka.netに直接serverspecする、なんちゃってCIだった。 masutaka.netにcookしてからPRを出して、WerckerにCIさせていた。 WerckerとAWSを連携させて、テストのたびにサーバをまっさらな状態から作り、終わったら破棄することが可能になったので、ここに記録しておく。去年くらいに話題になったこの辺の話。 Vagrant + Chef Solo + serverspec + Jenkins でサーバー構築を CI - naoyaのはてなダイアリー naoya/circleci-serverspec なんで今までやらなかったかというと、cookが一発で通らないレシピになっていたから。。気づいてはいたんだけど、本番サーバのテストが通りさえすればよかった