Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

tokenは左メニューのAccountSettingより API Tokens を選択して取得できる。 使い方 現在のブランチのビルドを起動する。 まだAdd Project とかしていないプロジェクトだと何も置きずに止まるだけっぽい。 Add Project しているプロジェクトだとgithubから最新のBranch Tipを取ってくる。 Github 連携かけている場合ほとんど必要ない? udpate Build status Failed Started at Oct 11, 3:33 AM Finished at Oct 11, 3:33 AM Steps: Starting the build Start container Enable SSH Restore source cache Checkout using deploy key: xx:xx:xx:xx:xx:xx:x
@eaglesakura です。 私はCIのサービスとしてCircle CIを使用しています。 Jenikinsとくらべて良い点も悪い点も多くの記事で語られていますが、ここでは実際にどういう形でプロジェクトを運用しているか解説します。 Androidアプリ開発のテンプレート設定 私の場合は次のような設定をほぼテンプレートとして使用しています。 この状態からプロジェクトの要件に合わせて変更をかけます。 checkout: post: - git submodule update --init - chmod 755 ./gradlew - chmod 755 ./script/developer-install-private.sh # ここにビルド用スクリプトの実行権限を追記していく... machine: timezone: Asia/Tokyo java: version: oracl
こちらの記事ではCircleCIとCodeDeployの、基本的な連携しかたを紹介しました。この記事では、ステージング環境と本番環境のデプロイを分離する手順を紹介したいと思います。 #考え方 作成しやすさとセキュリティのバランスを配慮した結果、最初の記事で作成した以下を使いまわします。 IAMロール CodeDeployのアプリケーション CircleCIがデプロイを行うためのIAMユーザ 一方、以下は新しく作成します。 リビジョン保存用のS3バケット CodeDeployのアプリケーション内のデプロイグループ(deploy_group) また、インスタンスとブランチの関係は以下。 本番環境 → 今まで使用したインスタンスを使いまわす ステージング用の環境 → 新しく作成 GitHubのproductionブランチ → 本番環境用ブランチ GitHubのmasterブランチ → ステージン
今回はCircleCIを1行追加するという簡単な作業で複数コンテナにバランシングしてしまうよ!というお話です。 CircleCIで並列処理をやっている方は是非試してみてください! 詳しい内容は以下。(英語) http://blog.circleci.com/announcing-automatic-test-balancing/ 何が変わるの? 今までは複数コンテナへちょうどよくテストを振り分けるのを手動なり何なりでやってました。 https://circleci.com/docs/parallel-manual-setup これが1行Gemを追加することで上記作業が必要なくなったというわけです! どうするの? さて肝心の追加する行ですが、Gemfileに以下の1行を追加して下さい。
GAE/GoのアプリをCircleCIからデプロイできるようにしたいと思います。AWSにデプロイするのとは違う感じなので、ドキュメントを読みました。以下はAppEngine Flexible Environment へのデプロイになります。StandardEnvでも参考にはなると思いますが、違う部分もあるので注意してください。 また、flexible envはまだbetaなので、この辺りすぐに変わる可能性があります。 公式のドキュメント このあたりを読めば書いてあります。 Authentication with Google Cloud Platform - CircleCI Continuous Deployment to Google App Engine - CircleCI 以下では書いてあることを順にやっていきます。 GCPサービスアカウントの作成 まずは GCPのコンソールで
Vegewelというベジタリアンガイドを作っています。 ここではソース管理にBitBucketを使っており(プライベートリポジトリでもタダだし)そこからCircleCI使って本番環境とStaging環境に自動デプロイする仕組みを作りたいと考えました。 ソース手上げなんてマジでありえないので・・・。 ということでサーバ環境はAWSのクラウド環境では有名なPaaSであるElasticBeanstalk(以下EB)を使っています。Herokuの対抗馬ってことなんだろうけど多少はEC2やRDSの知識ないと使いこないせないのがミソです。 で、こちらがそのサーバです。 BitBucket上にはmasterに加えてstagingのブランチを切っています。 ここではアプリの作り方やBitBucketへのコミット、プッシュ、ブランチ作成方法は割愛します。 他のサイトで参考にしてください。 自動デプロイ使わな
Collate=CのPostgreSQLデータベースとは? PostgreSQLで感覚的に正しい日本語ソートを行うにはinitdb時に--no-localeオプションを付けて初期化を行う必要がある。CircleCIではデフォルトでUTF-8なので正しくテストを実行することができない可能性がある。 強制的にno-localeなDBを作り直す circle.ymlに次のように指定することでno-localeなDBを強制的に再作成することができる。 machine: ruby: version: 2.2.1 pre: - sudo locale-gen ja_JP.UTF-8 - sudo -E -u postgres PGDATA=/var/lib/postgresql/9.4/main /usr/lib/postgresql/9.4/bin/pg_ctl stop - sudo -E -u
GithubにCommitしたら、テストを実行して、EC2のWebサーバに自動的にdeployしてほしいよねーとかねがね思っている方用の手順です。EC2以外はそんなにお金かけたくないなという人もCircleCIならとっつきやすいかもしれません。 継続的イテレーションを導入すべくCIの中でも有名で1コンテナまで無料のCircleCIを導入。 以下作業メモ。 継続的イテレーション(CI)で開発したいよねって思ったら注意点ですが サーバインスタンスは作り直しになる Githubから直接EC2に上げる方法もあるけど意外と情報ないのでS3とCodeDeployも使う CircleCIはCIのツールでプログラムのdeployはCodeDeployが担当するという理屈を理解 というのがあります。私そもそもの理屈がよくわかってなかったです。 ※何か作業中におかしな挙動があった場合はこちらを使って調査してみ
2017/04 追記 CircleCI 2.0 で Docker のバージョンが上がったためキャッシュできるようになりました 以下は CircleCI 1.0 時代になぜできなかったのかの説明 やりたいこと CircleCI の Docker イメージビルドが遅い イメージキャッシュが引き継がれないため なんとかしてイメージキャッシュを引き継ぎたい TL;DR CircleCI の Docker バージョンが 1.10 の間は、無理 もう少しでなにかしらのアナウンスがあるらしい (https://discuss.circleci.com/t/request-docker-1-12/5120/13) Docker 1.11 対応を待つ tonistiigi/buildcache が使える Docker 1.13 リリース & 対応を待つ cache-from オプションが追加された Circ
担当しているプロジェクトがテストの実行もデプロイも手動だったので、 テストとデプロイの自動化に挑戦してみました。 バージョン管理はGitHub、サーバーはEC2を使っていることもあり、 今回のケースでは無料で実現できるCircleCIとAWS CodeDeployを使います。 こちらの記事に沿う形で行いました。 CircleCIとAWS(CodeDeploy/S3)で作るCI環境 構築したいこと 特定ブランチにpushすると、CircleCIでテストされ、OKなら指定のEC2インスタンスにデプロイする cronはgitで管理し、デプロイ毎にcronを更新する デプロイ毎にpip install requirements.txtなど依存ライブラリのインストールを行う 0. 事前準備 aws account作成 GitHub account作成 GitHub にデプロイしたいのリポジトリを作成
circle.ymlの準備 circle.ymlファイルを作って、プロジェクトRoot直下に置く。 Javaの設定 参考 CircleCI側の準備 GitHubアカウントがあればSign upできる。 https://circleci.com/ プロジェクトを追加 [Add Projects] からCIしたいリポジトリ選んでビルド! https://circleci.com/add-projects これで以降pushを契機にCIが走るようになる。 Slack側の設定 Slack側の設定 integrationにCircleCIを追加する https://my.slack.com/apps https://my.slack.com/apps/A0F7VRE7N-circle-ci [Add Configuration] 通知したいチャンネルを選んで、Webhook URLを控える アイコン
cloudpack大阪の佐々木です。 以前、CFn → Ansible → ServerspecをCircleCIでCIする http://qiita.com/taishin/items/89b42106582a2aa5495b というのを書きました。 このときはCFnとAnsibleを同時にテストするという方法をとっていたのですが、 これらは分けて管理した方がいいような気がしてきました。 なので、Ansibleのgitリポジトリをプッシュした時に、AMIを作成するようにしてみました。 EC2の起動はaws-cliでもいいのですが、前のCFnをそのまま使いました。 circle.ymlでやっていることは下記です。 pre部分 CFnでEC2を起動 ansibleでデプロイ override部分 ansibleでデプロイしたインスタンスのAMIを作成 作成したAMIを使って、CFnでEC2を
cloudpack大阪の佐々木です。 またもCircleCIです。 今度はCloudFormationをテストをCircleCIでやってみます。 テストはawspecを使います。 awspec 設定 ソースコードはこちらに。 https://github.com/taishin/cfn-ci CloudFormation template.cform VPC上にEC2を1台たてているだけです。 CloudFormationで作成されたリソース(セキュリティグループ等)は、名前にランダムな文字列が付与されていたり、テストコードに代入しにくいので、Tagで名前を設定しています。 awspecテストコード EC2 EC2はImageID、InstanceType、パブリックIPアドレスをもっていること、 適用されているセキュリティグループ、VPC等の確認をしています。 ####で囲まれている部分
動機 最近、Electronのアプリを作り始めました。 出来上がった機能をすぐに公開したいので、CircleCIでmac用のappファイルを作成し、GitHubのReleaseに上げる事にしました。 ただ、masterの変更の度にバージョン番号を上げるのも面倒だし、Releaseのタグが大量にあるのも微妙な気がしました。 (なにより、毎回tagを手動で作るのもめんどい) そこで、Releaseは毎回"更新"し、package.jsonのversionが変わっている場合のみReleaseを"追加"することにしました。 普通は逆というか、普通のフローとは違いますね。。 例: Releaseにv0.0.1が存在するとき、versionが0.0.1のままmasterが更新 以前のタグ・Releaseを破棄、最新のmasterでv0.0.1を再作成。 Releaseにv0.0.1が存在するとき、ve
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く