circleciのbuild/test/deployをgithub actions(beta)に移行した - 839の日記
まだ機能的に足りないところもあるが、頑張ったら使える感覚だった。 githubにもfeedbackが送れる所があれば送ろうと思う。 circleciでやっていたことはざっくり書くと以下。 test系 golangのbuild/lint/test helm chartのlint helm templateで吐き出されたyamlのlint build系(only master) base imageのbuild & push k8s上で動かすprod imageのbuild & push deploy系(only master) GKE上にhelm secrets upgrade これをgithub actionsに移行した際にcircleciとの差分を感じた機能は以下。 slack通知 自分のリポジトリでは未実装、デフォルトは失敗するとメール通知が来る 未確認だが多分いろいろな人がbeta向
3分でできる！最高のDockerfileを書いたあとにやるべき1つのこと - Qiita
概要 Dockerfileを書くためのベストプラクティスを読んで、ベストプラクティスなDockerfileを作った/作りたい人が対象です。 そのDockerfileで大丈夫かを3分でチェックできるツールをつくりました。Hadolintのような、単なるDockerfileのLinterではなく、ビルドしたイメージの中身まで細かく分析します。 通常のLinterでは原理的に不可能な、ベースイメージに存在している危険性も含めて調べることができます。 ←GitHubのStarもらえると嬉しいです。 Dockleの内部で使われているツールはTrivy, Vulsなどと同じなので、そのあたりを踏まえて、動作原理を別記事にまとめました。 人を震えさせるツール｢Dockle｣の仕組みを解説 なお、DockerHubで人気のコンテナに対して試した結果をサイトにして公開しています。操作方法もふくめて、別記事に
AWS CodeStarを使って，Django製アプリをデプロイするまで - Qiita
環境 AWS CodeStar Python: 3.6 pipenv: 2018.7.1 pip: 18.0.0 Django: 1.11.18 執筆したきっかけ 研究で開発する実験用システムをデプロイするため AWSに（ちゃんと）初挑戦する！ 開発するシステムをそれなりな環境で動かす必要があるため，herokuじゃ厳しそう 毎度手作業でデプロイするのがしんどい CodeStarとは AWS CodeStar を使用すると、アプリケーションを迅速に開発および構築して AWS にデプロイできます。 AWS CodeStar とのこと． つまり，「CI/CDも含めたWEBアプリの開発環境を，お手軽に構築するよ！」というサービスです． 対応する言語やフレームワークがたくさんあり，困ることはなさそうです． ちなみに，2019-05-22時点では， Go Node.js Python, (Flask
いまさらだけどCircleCIに入門したので分かりやすくまとめてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今度入社する会社では、JenkinsでなくCircleCIを使っているということなので、1から勉強した内容を初心者向けにまとめました。 また、最新バージョン2.1(2018/12時点)の新機能も本記事では触れています。 ※2019/8/8追記 Slack連携に関する記事も書きました。 SlackでCircleCIからカバレッジレポート通知を受け取る設定手順 ※2020/4/2追記 https://twitter.com/CircleCIJapan/status/1245253320551399424 CircleCIさんより、
AWSにおける本番環境を想定したCI/CD実践 - y-ohgi's blog
この記事は DMM.com Advent Calendar 2018 - Qiita の25日目です。 About CircleCIとCode兄弟を使いCI/CDを作っていこうというものです。 単純に環境を作るわけではなく、CloudFormationを使って本番環境を想定した構成にしていきます。 ターゲットとしては既にCircleCI・CodePipelineをざっくり知っている人で、本番向けのCI/CDをどのように構築していくかについて自分なりのプラクティスを紹介します。 サンプルコード 今回の構成を再現するためのコードを用意しました。 https://github.com/y-ohgi/ci-cd-example CloudFormation 環境はCloudFormationで管理しているため以下のコマンドで再現できます。 VPC、Aurora、ECS、CodePipelineなど
コンテナデプロイ基盤の検証 - Hatena Developer Blog
はじめに はてなサマーインターン2018の大規模システム開発コースの成果報告をします。 今年は、メンターのid:cohalzさん、id:wtatsuruさんの下、実際に使われているサービスをAmazon ECS(Elastic Container Service)にデプロイする基盤を構築しました。 コンテナでサービスを本番運用するために、AutoScaleの検証や、デプロイ時間の計測、改善策の検証を行いました。また、開発、デプロイフローを楽にするために、AWS CodeBuild、CodePipelineを使ってCI/CDの構築も行いました。これにより、PullRequestごとにCIが走り、masterにマージされたら自動でECSにデプロイすることができるようになります。高速なデプロイ切り替えを行うために、Blue-Green Deploymentの検討も行いました。 他にも、Micro
OSS雑メンテ #railsdm - くりにっき
Rails Developers Meetup 2017 というイベントで「OSS雑メンテ」という発表をしたのでスライドをシェアさせていただきます スライド 発表中の反応 他の人のスライド スライド 発表中の反応 OSS雑メンテ 末吉さん #railsdm— シロ (@shiroemons) 2017年12月9日 黄色のプリキュアのsueさん！ #railsdm— kaiba (@kaiba) 2017年12月9日 栗のアイコン見たことある！ #railsdm— 🌈 (@ppworks) 2017年12月9日 毎年プリキュアのAdvent Calendar立ててる人だ！ #railsdm— 黄色 (@iyanayatudaze) 2017年12月9日 一瞬カラフルな背景が見えた #railsdm— ゆっき：Lv6 (@yucky_sun) 2017年12月9日 栗の人だ #railsdm
RailsにSideCIとCircleCIをそれぞれ導入する - Qiita
はじめに RailsアプリにCIツールを導入して、コードの自動解析やテストやデプロイを自動でやりたかったので 比較的簡単に導入できそうなSideCIとCircleCIを使ってみました。 その時の導入方法や使ってみた所感をつらつら書きます。 リポジトリやコードはあくまで参考にしてください。 こんな時に使える コードの品質を一定にしたい レビュアーの負担を減らしたい プルリクエストに対して自動でテストやデプロイしたい CIの結果をslackに通知したい もろもろ自動化したい SideCI 概要 公式 : https://sideci.com/ プルリクエストを自動で解析し、セキュリティバグ、コード規約、文法、重複記述、未使用の変数、複雑度を検知します 準備 Githubのアカウントがあれば利用できます。 Githubと連携してアカウント登録します。 パブリックリポジトリは無料ですが、プライベー
続・開発環境のツール周りをちょっと快適にした話 - ぐるなびをちょっと良くするエンジニアブログ
こんにちは！パンダ大好きエンジニア、宮原です。 前回（開発環境のツール周りをちょっと快適にした話）の記事では、チームで導入した開発支援ツールについて、どんなツールがあるのか、どんな考えで導入したのか、というところをご紹介しました。 開発支援ツール導入後はコードの品質も上がって（潜在バグの低減、保守性の向上）、快適に開発ができるようになりました。現在はCIサーバによる監視も実現できており、もっと開発が快適になりました！ 今回は、CodeIgniterというPHPフレームワークに各開発支援ツールをどのように導入し運用しているのか（CIサーバを活用したツール実行方法）をもっと具体的に紹介していきたいと思います。 目次 リポジトリ（ディレクトリ）の構成 各ツール用ディレクトリの詳細 PHP Coding Standards Fixer PHPMD PHPLOC PHPCPD phpDocument
特定のブランチをもとに本番同様の動作確認ができる「レビュー環境」の話 - 弥生開発者ブログ
こんにちは。tkykです。 みなさん、コードレビューしていますか？今日はMisocaのレビュープロセスで用いられている、とっても便利な「レビュー環境」について紹介します。 Misocaのレビュー体制とその課題 MisocaではPull Request（以下、PR）ベースの開発体制をとっており、必ず他のエンジニアによるPRのレビューを経てから、masterへマージすることになっています。 レビュー時に動作確認をするには、エンジニア各自がローカル環境にブランチをチェックアウトして行うのですが、時にはそれだけでは不都合なケースもあります。 非エンジニアにも動作確認をしてほしい 動作確認をするための条件を整えたい 最終的にはマージされないコードを一時的に追加したい 依存するライブラリのバージョンを変更したい RAILS_ENV=production でビルド・実行したい などなど このようなケース
GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [紹介編] | ORIH
GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [紹介編] 夏休みをゲットしたのでサーバーレスなツールを作ってみました. 前々から気になっていた AWS CodeBuild をさわってみて、不足してるなと感じた部分を補完するツールです. TL;DR toricls/github-codebuild-integration | GitHub どんなものを作ったか こんなものです. 説明はいいからとりあえず使ってみたいんだけど、という方は下の方までスクロールしてもらって「とりあえず使ってみたい」セクションをご覧ください. 図の左下からフローが流れ、 GitHub リポジトリへの Push/Pull-Request を Webhook で SNS が受け取る CodeBuild のビルドジョブを実行する ジョブの完了を待つ ビルド結果を GitHub
Gitlab CI を使ってみるメモ - ngyukiの日記
Jenkins からの移行のために今更だけど使ってみたメモ。 なお、うちの Gitlab はソースから入れていてデータベースも MySQL です。たまにしかバージョンアップしていないのでちょっと古いです(8.17.2)。 参考 https://docs.gitlab.com/ee/ci/ 公式のドキュメント https://docs.gitlab.com/ee/ci/yaml/README.html .gitlab-ci.yml のリファレンス https://docs.gitlab.com/ee/ci/runners/README.html Runner のドキュメント https://docs.gitlab.com/runner/ 公式の Runner の実装のドキュメント https://gitlab.com/gitlab-org/gitlab-ci-multi-runner ↑のリ
試行錯誤してたどり着いた現在のiOSアプリ自動デプロイ環境（Bitrise、fastlane、Crashlytics、たまにbuddybuild） - 百戦錬磨 Techブログ
みなさまはじめまして。仙台在住。ビールを愛し、ビールに愛された男。麦芽系エンジニアのasmz（id:asmz0）と申します。 弊社は公認民泊プラットフォーム「STAY JAPAN」というWebサービスの開発・運用をメイン事業としておりますが、私はそのサービスのスマートフォンアプリ開発を担当しております。 STAY JAPAN - Business and Vacation Rentals Tomareru, Inc.TravelFree 仙台iOS開発者勉強会へ参加 実は私、東北出身ということもあり、新卒から十数年ほど過ごした首都圏を離れて仙台にJターンしてきたわけですが、仙台に引っ越してきたのは2016年8月なので、まだ仙台で住んで１年にも満たないのですよ。 で、社内もWeb系メインだし、まだ仙台に知り合いの社外エンジニアも多くなく、iOSアプリの開発話や苦労話などする相手がいないなぁと
mysqldiff を使って継続的に MySQL のデータベーススキーマの差分をチェックする - kakakakakku blog
最近，環境ごとのデータベーススキーマの差分をチェックする機会があった．プロダクション環境とステージング環境ならまだしも，開発環境だと検証のために追加したインデックスがそのままになっていたり，開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり，そういうことって比較的あるのではないかなと思う．特に今の環境だと，マイグレーションの仕組みが整っていないという課題もあり，より一層，データベーススキーマに差分が出やすくなってしまっている． 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした． mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている．現在だと v1.6 が最新になっている． MySQL
テスト自動化研究会 - テスト自動化の8原則
1. 手動テストはなくならない 2. 手動でおこなって効果のないテストを自動化しても無駄である 3. 自動テストは書いたことしかテストしない 4. テスト自動化の効用はコスト削減だけではない 5. 自動テストシステムの開発は継続的におこなうものである 6. 自動化検討はプロジェクト初期から 7. 自動テストで新種のバグが見つかることは稀である 8. テスト結果分析という新たなタスクが生まれる これらの原則は、どのようなドメイン、プロセス、ツールの現場におけるテスト自動化であっても共通して言える、テスト自動化に取り組む前に留意しておくべきことがら＝原則を、テスト自動化研究会のメンバーによる議論のうえ、絞り込んだものです。これからテスト自動化に取り組まれる方、現在取り組まれている方、これから見直しをされたい方にご参考いただければ幸いです。 解説 1. 手動テストはなくならない ユーザビリティテ
Travis CIでdepを使う - くりにっき
zatsu_monitor でdep対応をしたのでその時のメモ depについて .travis.yml depをいれたメリット depについて depについては下記を参照 mattn.kaoriya.net .travis.yml 必要最低限だとこんな感じ language: go go: - 1.7 - tip before_install: - go get github.com/golang/dep/... install: - $GOPATH/bin/dep ensure script: - go test depのREADMEに書いてるのを.travis.ymlに書いただけです。 .travis.ymlの完全版はこちら https://github.com/sue445/zatsu_monitor/blob/c265f1b9301c056cbac5006952270812c915
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Apps Script のデプロイを Circle CI から行う - Qiita
Yarn + CI + GitHub で挑む npm パッケージの定期更新
劇的改善 Ci４時間から５分へ〜私がやった１０のこと〜
移動しました - SmartHR Tech Blog
