Amazonのチームはどのように継続的デリバリーを行っているかSpring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
[レポート] DEV317: 高度な継続的デリバリーのベストプラクティス #reinvent ｜ DevelopersIO
Approvalアクションをトリガーとしたテスト例 Approvalアクション -> Amazon SNS -> AWS Lambdaと連携し、Lambdaファンクションでテストを行う。 Post-deploymentテストの作成 セグメント化のまとめ セグメント化してデプロイすることで不具合等の影響を小さくできる 最小のセグメント化 リージョン リージョンごとのカナリアデプロイ それより大きなセグメント化 アベイラビリティゾーン サブゾーン 各セグメントが稼働する前にテストをする マルチプルリージョンへのデプロイ クロスリージョンデプロイ 2018年11月に新機能追加 ひとつのパイプラインからクロスリージョン/クロスアカウントへのデプロイが可能になった 低レイテンシと高可用性を実現する パイプラインにガバナンスを実装 非準拠のパイプラインをブロック 紹介した変更を導入したり、新しいパイプ
![[レポート] DEV317: 高度な継続的デリバリーのベストプラクティス #reinvent ｜ DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/69d5e5df38c6d27d133baa3f894a2379a68db070/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_reinvent-2018-city_1200x630.jpeg)
CI/CDツールとS3を活用してREST APIやMQTTの通信仕様をステークホルダーと共有する | DevelopersIO
このブログを公開した数日後にAWSからサーバーレス開発者ポータル提供開始の案内がありました。 ケースバイケースですが、APIのドキュメント公開についてはサーバーレス開発者ポータルの利用も有力な選択肢になりそうです。 API Gateway のポータルサイトを簡単に構築できるサーバーレスアプリを試す サーバーレス開発部@大阪の岩田です。 サーバーレス開発部の良くある案件パターンとして、Web APIのバックエンド開発やIoTを絡めた案件が挙げられます。 こういった案件では通信仕様の設計からクラメソで対応することが多いのですが、プロジェクトを円滑に進めるためには単に通信仕様を設計するだけでなく、呼び出し側のお客様や他社ベンダーとの認識合わせや仕様の調整が重要になってきます。 現在関わっている案件では、GitリポジトリへのPushをトリガーにS3にドキュメント類をアップロードし、S3の静的Web
初めてのサーバーレスアプリケーション開発 ～Serverless Framework を使ってAWSリソースをデプロイする～ | DevelopersIO
初めてのサーバーレスアプリケーション開発 ～Serverless Framework を使ってAWSリソースをデプロイする～ 以前のエントリでは、GUIで簡単なサーバーレスアプリケーションを構築する方法を学びました。 初めてのサーバーレスアプリケーション開発 ～DynamoDBにテーブルを作成する～ 初めてのサーバーレスアプリケーション開発 ～LambdaでDynamoDBの値を取得する～ 初めてのサーバーレスアプリケーション開発 ～API GatewayからLambdaを呼び出す～ GUIで入力内容を確認しながらリソースを作成しサービスに対する理解を深めることは重要なことです。ですが、実際の開発でGUIをポチポチするのはちょっと面倒ですよね。 ということで今回は、以前GUIで作成したAWSの各リソースをServerless Frameworkを使って一撃構築してみようと思います。また、次
初めてのサーバーレスアプリケーション開発 ～Serverless Framework と Codeシリーズを連携させる～ | DevelopersIO
Serverless Frameworkで開発したアプリケーションをCodeシリーズを使ってAWS上にデプロイしてみます。 デプロイ対象のServerless Frameworkのサービスは前回のエントリ初めてのサーバーレスアプリケーション開発 ～Serverless Framework を使ってAWSリソースをデプロイする～で作成したものを利用します。 前提となる知識もありますので、必要に応じて以下のエントリも参考にしてください。 初めてのサーバーレスアプリケーション開発 ～DynamoDBにテーブルを作成する～ 初めてのサーバーレスアプリケーション開発 ～LambdaでDynamoDBの値を取得する～ 初めてのサーバーレスアプリケーション開発 ～API GatewayからLambdaを呼び出す～ 初めてのサーバーレスアプリケーション開発 ～Serverless Framework を使
.NET Core + SQL Server のユニットテストを Bitbucket Pipelines で動かしてカバレッジレポートを作成する - Qiita
.NET Core + SQL Server のユニットテストを Bitbucket Pipelines で動かしてカバレッジレポートを作成する Java から .NET Core に入門した身としては CI をどうするかはよくわからない問題です。 VSTS や Visual Studio にべったり依存すれば方法はあるのかもしれませんが、 なるべく GUI ツールではなく、テキストベースのスクリプトでビルドやテストができるような方針でありたいものです。 そこで最初に考えたのは、 Jenkins 2 系の Jenkinsfile のビルドスクリプトを使ったものでした。 当時は .NET Core Linux 向けのカバレッジ計測が出させるライブラリがなく、Windows サーバーで動かし OpenCover を使っていました。 Ver.UP で動かくなったり、ライブラリの導入自体が面倒だっ
How to Build a Secure-by-Default Kubernetes Cluster with Basic CI/CD Pipeline on AWS | Amazon Web Services
AWS Partner Network (APN) Blog How to Build a Secure-by-Default Kubernetes Cluster with Basic CI/CD Pipeline on AWS By Matthew Sheppard, Solution Principal at Slalom By Donald Carnegie, Consultant at Slalom As users and engineers of modern web applications, we expect them to be available 24 hours a day, seven days a week, and to be able to deploy new versions of them many times a day. Kubernetes i
npm ciを使おう あるいはより速く - Qiita
人類はより高速にCIを回していくべきだと思っている りんご（@mstssk）です。 先日、 npm の v5.7がリリースされ npm ci というサブコマンドが新たに追加されました。 The npm Blog — Introducing npm ci for faster, more reliable... http://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable CI/CDを開発プロセスに組み込んでいる場合により整合性があり高速なエクスペリエンスを提供する、と公式ブログでは紹介しています。 npm ci は何をするのか npm ci を実行すると常に package-lock.json から依存関係をインストールします。 既に node_modules フォルダの中身があっても
AWS Lambda（Python） の開発環境・テスト・デプロイ・CI 考察 | DevelopersIO
作るもの ヒーローを管理する Lambda Function を書きます。ヒーロー情報は DynamoDB の ヒーローテーブルに格納するものとします。リポジトリは以下。 * Python Lambda SAM + SAM Local Project コーディング作業 すべてはコードを書くところから始めます。いきなりプロジェクトルートにファイルを置いて書き始めるのも良いですが、後々テストやデプロイも行うことになるので少し整理してみます。以下のようにしました。 . ├── buildspec.yml ├── deploy.sh ├── docker-compose.yml ├── environments │ ├── common.sh │ └── sam-local.json ├── integration_test.sh ├── requirements.txt ├── src
インフラの継続的デリバリー - naoyaのはてなダイアリー
事前に断っておくがここでいう「インフラ」はレイヤ的には OS より上の話。 少し前に GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー で、GitHub を介したデプロイを実践しているということを紹介した。普段の開発を Pull Request ベースでやっているので、デプロイもまた Pull Request を契機に実行させると色々捗る、という話。 このプラクティスの対象領域をインフラにまで拡大してみました、というのが今回の話。 DNS レコードを Pull Request を merge した契機に自動で更新 AWS を利用している場合、ドメインの管理も Amazon Route 53 を使うといろいろと都合がいい。 Route 53 での DNS レコードの更新はこれまでブラウザから操作していた。これだと誰がいつ作業したかわからないし履歴もトラックしづらい。また変更
膨大なビルド・テストで泣かないための継続的統合／CI実践ノウハウ
膨大なビルド・テストで泣かないための継続的統合／CI実践ノウハウ：DevOps時代の開発者のための構成管理入門（4）（1/3 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする。今回は、Jenkinsをはじめ、ツールが格段に使いやすくなってきた継続的インテグレーションについて、概要やメリットに加え、実践ノウハウを事例とともに紹介。 今回は、継続的な統合（Continuous Integration、CI、継続的インテグレーション）について紹介します。 CIとは、継続的な統合とは 皆さんは、CIという言葉を聞いたことがあるでしょうか？ CIとは、1度限りもしくは数回限りではなく、継続的に小まめにビルドを実行して
Backlog(Git)とJenkins(MSBuild)を連携させ、自動ビルドさせる - .NETで作る！
BacklogにあるGitリポジトリとJenkinsを連携させ、CIってのをやってみたいと思います。 環境 Windows 7 64bit Jenkinsのインストール まずはこちらのサイトからJenkinsをダウンロード、インストールしましょう。 jenkins-ci.org IISも不要で、特に悩む点もありません。*1 インストールが終われば、 http://localhost:8080/ で起動できます。 Jenkinsの設定－アドイン 「Jenkinsの管理＞プラグインの管理＞利用可能タブ」からアドインを追加しましょう。 MS Build Git Plugin GIT client plugin*2 Backlog plugin 強制的にJenkinsを再起動したい場合は http://localhost:8080/safeRestart このページで実行できます。 Jenkins
コードの健康状態を保て！ Jenkinsとtestemを使って、JavaScriptで継続的インテグレーション（CI）を行う
対象読者 JavaScriptの基本をある程度理解している方 テストコードをこれから書こうと考えている方 継続的インテグレーションで「コードを健康的な状態に保つ」 皆さんはどのように開発したコードのテストとビルドを行っていますか？ もう15年ほど前になりますが、筆者が行っていたJavaプロジェクトの方法を紹介しましょう。 テキストエディタでJavaのコードを修正 共有ディレクトリにコピー システムすべてのコードをコンパイル システムすべてのコードをjarファイル化 共有開発環境を手動シャットダウン 共有開発環境に手動ビルド 共有開発環境を手動起動 手動で画面から動作テスト エラーが起きた場合は1.に戻る 箇条書きにするとやることが多いですね。もしかすると古いシステムを開発されている方々は、これと近い方法でテストをしている場合もあるのではないでしょうか。何をやっているかはわかりやすいのですが
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
第2回 大規模Windows環境におけるデプロイ | gihyo.jp
ASP.NET（C#）におけるビルドとデプロイ 私たちの会社ではASP.NET MVCという.NET Framework上で動くWebフレームワークを使って開発しています。前回書いたとおり、開発言語にはC#を採用しています。 C#で書いたコードを.NET Framework上で動作させるには、コードをビルドして実行可能なバイナリを生成する必要があります。正確にはCILという中間言語にコンパイルし、CLRと呼ばれる共通言語ランタイムが実行時にネイティブコードにコンパイル（JITコンパイル）しながらプログラムを実行します。ASP.NETの場合、Windows Server上に構築したIISと呼ばれるアプリケーションサーバ上で動かすことが多いですが、その場合もビルドして生成されたバイナリをIISにデプロイします。このとき、C#で書かれたコードは拡張子dllを持つバイナリファイルに変換され、設定フ
DevOps時代の開発者のための構成管理入門
「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする ソフトウェア開発で構成管理が重要になった5つの理由 DevOps時代の開発者のための構成管理入門（1） 開発と運用の協力を目指す「DevOps」含め、いまの構成管理を取り巻くトレンドや、その必要性などを5つの項目で解説する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Provisioning & Deploy on AWS
hands-on/fargate at master · jawsug-container/hands-on
Toru Makabe on Twitter: "これですよね これを普通にするといろんなしがらみから解放される だからワイもk8sの中にはデータストアは持たない派 "一日一回CIでVPCを削除してゼロから再構築する" / kintone on EKS ― EKS で実現するイン… https://t.co/e7LhtsEvAc"
Azure Websitesの継続デプロイで使うプロジェクトを選択する | MasuqaT.NET@Blog