Default machine executor image update
EDIT: Due to the customer feedback we have received we’ve decided to not change the default image for the machine executor in April 2019. We are now working on a plan for making this update safer and more compatible for customer jobs. We will update here as we have a new date for the change and a plan for rolling the change out. We are excited to announce a new machine executor image with Ubuntu 1
Quickstart guide - CircleCI
This quickstart provides a guided tour through setting up a project, collaborating, and tools to iterate on and debug your build configuration. The following sections cover the following: Create a project, connecting some existing code to CircleCI. Inviting team members to collaborate on your new project. Use the VS Code extension to debug and extend your config. SSH into a build to debug your pro
CircleCI 2.0 でNode.jsのマルチバージョンビルド - teppeis blog
追記 2017/07/11 CircleCI 2.0 GAがリリースされたので、curlではなく標準機能Workflowsを使ったバージョンを紹介する記事を書いたので、こちらをご参照ください。 CircleCI 2.0 GAリリース: 続Node.jsマルチバージョンビルド - teppeis blog 追記終わり。 CircleCI 2.0が高速でカスタマイズできて最高だという話と、Node.jsのマルチバージョンテストのやり方、キャッシュ戦略などを紹介する。 前提として、以下はnpmパッケージのようなユニットテストでほぼ完結するシンプルなライブラリのCIを想定している。 サービスやアプリ開発のCIは要求が違ってくるのでまた別。 先に結論としてサンプルプロジェクトを貼っておく。急ぎの方は.circleci/config.ymlをコピペして “How to use” だけ読んで設定したらO
Orchestrating Workflows - CircleCI
Workflows in CircleCI are used to orchestrate jobs. Workflows have options to control run order, scheduling, and access to resources. This page explains how to configure workflows to suit your project. Optimizing your workflows can increase the speed of your software development through faster feedback, shorter reruns, and more efficient use of resources. A workflow is a set of rules for defining
TravisCIとCircleCIでちょっとずつ違うビルド環境の考え方の違い
tl;dr TravisCIとCircleCIの根底にある違いの考え方を理解すると早い。 そして、違いを考慮しているproductを使うと便利。 e.g. checkstyle形式の結果をpull request review commentするsaddler CI result 考え方 CircleCI pushされたbranchをビルドする。 TravisCI pushされたbranchをビルドする。 pull requestのbranchを、仮にmasterにmergeしてみて、ビルドする。 仮にmasterにmergeしてみて?? TravisCIの二つ目のがわかりにくくて、混乱する。 やっていることは正しいんだけど、挙動が直感から外れるので、 TravisCIヘビーに使っているユーザーにもわりと意味不明挙動扱いされやすい(要出典) pull requestするとtravisのビル
golangで書いたツールをCircleCI上でビルドしてその成果物をGitHub Releasesにリリースする - その手の平は尻もつかめるさ
表題の通り．いくらかポイントがあったのでメモとして記す． 基本的にこの記事の内容を真似した． medium.com あらかじめ，CircleCIの側の設定でGITHUB_TOKENという環境変数を登録しておく．なおGitHubのPersonal access tokenにはrepoのpermissionを付与しておく． とは言えこれでは動かない．理由はghr (ghrについてはこちら: 高速に自作パッケージをGithubにリリースするghrというツールをつくった | SOTA) がcontextに依存しているからで，contextはgo 1.7以降でないと利用できない．しかしながらCircleCIのgolang環境は1.6系が使える内の最新なので *1 このままではghrをgo getすることが出来ない． というわけでCircleCI上でgo 1.7を使うようにしましょう，ということでそう
CircleCI で composer を高速化させる - OTOBANK Engineering Blog
こんにちは！@riaf です。 今日は PHP BLT #1 ですね！ (LTネタの仕込みもせずにこんな記事を書いていて良いのでしょうか) 弊社では、サービスの CI / デプロイ等に CircleCI を利用しています。 最近の PHP 開発では、Composer を使うことが多いと思うのですが、Symfony Components とかを使い始めると、依存するパッケージが多くなってしまって、CI 時の composer install に思いの外時間がかかってしまうこと、ありますよね。 特に、頻繁にテストが行われるようになると、Composer が GitHub の API リミットに引っかかってしまい、アーカイブではなくソースコードを clone してリミットを回避するので、より時間がかかるようになってしまいます。 「どうにかしたいですよねー」という声が上がってきたので、「よーし、い
継続的インテグレーションで実現するWebメディアの執筆フロー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに Webメディアの執筆作業に継続的インテグレーション(Continuous Integration)、継続的デリバリー(Continuous Delivery)の考えを取り入れ、GitHub/CircleCIを使って効率化をした話です。最初の環境構築さえしてしまえば、非エンジニアでも問題なくこの仕組みに乗ることが出来ています。これらのツールは発想次第でいろいろな使い方ができるということを、メディアの運営者やエンジニアに限らずいろいろな人に知って頂ければ良いのかなと。 背景 この仕組みは私がWebメディアを運営する会社にて、開発と
CircleCI で Docker Container を Serverspec でテストする
Serverspec の Docker Backend を使った Docker コンテナのテストを CircleCI 上で実行する際、多少手こずったので、その試行錯誤によってできた、サンプルプロジェクトを公開しました。 GitHub Repository quay.io Registry CircleCI Builds 前回の記事で紹介した事例は Rails を採用していたので、コンテナ側にも Ruby がインストールされており、コンテナ側にマウントするだけで Serverspec を実行できました。 docker run \ -e DATABASE_URL="${DATABASE_URL}" \ -e REDIS_URL="${REDIS_URL}" \ -v "$(pwd)/docker/serverspec"\:/mnt/serverspec \ --name "serverspec
Jenkinsと完全にサヨナラして、CircleCIに移行した話 - tehepero note(・ω<)
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
Continuous Integration and Deployment on CircleCI just got better: now it’s free.
Continuous Integration and Deployment on CircleCI just got better: now it's free. Note from the publisher: You have managed to find some of our old content and it may be outdated and/or incorrect. Try searching in our docs for current information. Continuous Integration and Delivery are best practices for software development, and are part of CircleCI’s mission: to help developers move faster and
ChatOpsでOSのセキュリティアップデートを自動化出来るようにした - Glide Note
先日@naoya_itoさんが自身のブログ(インフラの継続的デリバリー)でKAIZEN platform Inc.のインフラについて書いていたやつの続編的な内容。 TL;DR Chat(Slack) + Hubot + CircleCI + GitHub を用いてセキュリティアップデートを自動化した GitHubのPull Requestを契機にセキュリティアップデートを実行できるようにした CircleCIが大変便利。インフラ系の作業を自動化するのに非常に合っている気がする 背景 KAIZEN platform Inc.では、 ネットワーク脆弱性スキャン アプリケーション脆弱性スキャン セキュリティアップデートの定期実行 の3つをセキュリティ系タスクとして継続的にやっていこうという話になり、今回は私が担当した、「セキュリティアップデートの定期実行」の話。 RHEL系OSにはyumの自動更
CI（継続的統合）as a Serviceの「Circle CI」がDocker対応を開始
Githubにコードをプッシュすると自動的にコードを取り込んでビルドが行われ、テストが走る。いわゆる「CI：Continuous Integration（継続的統合）」を実現するCI as a Servicesを提供する「Circle CI」が、Docker対応による継続的インテグレーション／継続的デリバリの開始を発表しました。 DockerファイルによってCircle CIで行うビルドとテスト環境を定義できるため、開発環境とテスト環境、デプロイ先の稼働環境などの違いを事実上なくせることが大きな利点だと説明されています。 You can now use all Docker functionality within our build environments. All of the usual Docker commands work as expected, so you can bu
CircleCI導入したのでwerckerとの比較も含めてまとめ - 月曜日までに考えておきます
最近話題のCI as a Serviceを導入すべく調査してみました。JenkinsさんもすごくいいのですがAWS smallインスタンスに乗せているとやっぱり本来の力を発揮できない感じがあるので。 CircleCIって以前は、一番安い契約だと1Private Repositoryしか扱えなくて使いづらそうな印象だったのですが、4月末頃にPrivate Repository数は無制限、同時実行ジョブ数で課金というPlanに変更になったようですね。 Simple and Transparent Pricing | The Circle Blog http://blog.circleci.com/simple-and-transparent-pricing/ 自分の関わっているプロジェクトでは、 リポジトリはそれぞれの役割ごとにいくつか分けている 開発者数は少ないのでコミット頻度はそんなに高く
GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー
少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。 最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分たちで環境を構築しなくてもクラウドに任せることができる。KAIZEN では CircleCI を積極的に使っている。 これらの CI as a Service は基本的に GitHub と連携するこ
CircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog
最近CIサーバーを自前Jenkinsから CircleCI に移した。CircleCIとても便利で簡単なのでオススメ。 CircleCIには普通のheroku deployは内蔵されているのだけど、 非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 、をやるにはちょっと工夫が必要。 色々書こうと思ったけど、めんどくさくなったのでscriptを晒しておくだけにしよう！ この中で使われているスクリプト関連、特に秘密にする部分もないのでpublicでgithubに置いている。 https://github.com/quipper/deploy-support-tools /circleci.yml deployment: feature: branch: /^(?!^master$).+$/ commands: - ./script/staging_deploy.sh pro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
移動しました - SmartHR Tech Blog
GitHub - circleci/encrypted-files: Storing encrypted files in source on CircleCI
why-we-broke-our-philosophical-vows-to-bring-you-circleci-2-0