# travis-ciからAmazon S3へファイルをデプロイする - Qiita
背景、目的 Amazon S3はクラウドスレージとしてのみだけでなく、静的なWEBコンテンツの配信元としても利用できる。Amazon S3へファイルをアップロードするツールは数あるが、コンテンツのバージョン管理としてGithubを利用している場合、ファイル配置とバージョンの紐付けを行う必要性が生じうる。今回は、CIサービスのtravis-ciを利用してこれを実現する。 手順 AWSにデプロイ用アカウントの作成 S3にバケットの作成、権限の編集 travis.ymlの設定 デプロイ用アカウントの作成 travis-ciからのデプロイは、専用ユーザーを作成しそのユーザーアカウントを利用してtravis-ciがAWSのAPIを叩く。まずは、AWSコンソールのIAMからグループを作成する。アクセス許可を設定し、S3へファイルのアップロードができるようにする。本当は細かく設定するべきだろうけど、今回
Work in ProgressパターンによるPull Requestを利用した開発フロー - Qiita
はじめに ソースコード管理ツールとしてGitlabやGithubを導入することで、ソースコードのバージョン管理に加えて、コードの変更前にコードレビューを実施するPull Requestを簡単に行うことができる。コードレビューの観点や手法は様々であるが、レビューを実施する前に幾つかのコンテキストをレビュー担当者とレビュー依頼者が共有しておくことでスムーズなコードレビューが期待される。 本文章ではWork in Progressパターンと呼ばれる手法を利用した、コードレビュー前のコンテキストの共有方法を紹介する。 コンテキストの共有 コードレビューを実施する前に幾つかのコンテキストを共有することは、レビュー担当者の負担削減や、レビューの品質向上またレビュー依頼者のタスクの明確化に繋がる。共有するべきコンテキストの一例として以下の物が挙げられる。 実装する機能の詳細設計 実装する機能の仕様 実装
Vagrant + Ansibleで複数のEC2インスタンスの起動、プロビジョニング - Qiita
コマンド1発で理想の環境ができあがるとうれしいですよね！僕は、嬉しいです！！ 開発環境や、本番環境など用途は色々ですが、同時にサーバーを幾つか建てて、動かして、削除する際にはVagrantと構成管理ツールが便利です。Chefとかpupetとか色々とありますが、手軽に定義ファイルを作って利用できるAnsibleを今回は利用します。 今回は、同じアプリケーションが動作しているけど参照しているDBが異なる5つのインスタンスの起動を行います。アプリケーションのデプロイが完了したamiからインスタンスを起動し、設定ファイルをホスト毎に切り替えます。 Vagrantfileを作る EC2を利用するので、vagrant-awsプラグインを事前に入れておいてください。 # -*- mode: ruby -*- # vi: set ft=ruby : # Vagrantfile API/syntax ver
Sprayでログの設定をする - Qiita
Sprayを利用したアプリケーションの実装を行う際、ログ出力は必須となりますが、そのあたりに関する設定のメモ。 日本語でSprayの記事って少ないですね。 LoggingContextにありますが、AkkaのLoggingAdapterをラップしてるようです。したがって、Akkaと同じ設定で利用できます。 ちなみに、ビルドにはsbtを利用している前提です。 logback.xml logback.xmlをsrc/main/resourcesに置きます。内容はLogbackのための設定なので、詳細については別の資料とかを見たほうが良いかと。 サンプルで、以下のを用意しました。 <configuration> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>application-debug.log</
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
