僕がOSS導入時に気にしてること - くりにっき
前置き 観点 GitHubやGitLabなどのリポジトリの場合 https://rubygems.org/ https://hub.docker.com/ 共通 (2019/12/29 11:30追記) 2019/12/29 11:30ブコメレス 前置き 社のesaに投下したものの反応が薄くて寂しいので全体公開 他人が作ったOSSを使うにあたって、もしあまりメンテされないOSSを使うと結局別のOSSに乗り換える必要があっておつらいので、僕がどんな観点でOSSを選択してるのかをまとめました あくまで僕が見ている観点なので異論は認める 観点 GitHubやGitLabなどのリポジトリの場合 Star数 多ければ多いほどいい 放置されてるIssueやPRの数 少なければ少ない方がいい オープンになってるPRがたくさんあってもちゃんとレビューされてマージされてるのであればいいんだけど、放置されてる
CIマニアから見たGitHub Actions(Beta)の使い所 - くりにっき
1ヶ月くらい使って勘所が見えてきたのでメモ メリット 1リポジトリ辺り20並列までジョブを並列実行できる ジョブ実行時はアクセストークンが勝手に設定されている マトリクステストがやりやすい 実際にGitHub Actionsに移行したプロダクト zatsu_monitor activerecord-compatible_legacy_migration index_shotgun デメリット yamlのanchorが使えない マトリクステストだとSlack通知がつらい 合わせて読みたい メリット 1リポジトリ辺り20並列までジョブを並列実行できる これに尽きる。 CircleCIにしろTravis CIにしろorganization(user) *1単位で並列数が縛られているため、例えば同じuserの他のリポジトリでジョブが詰まっていると別リポジトリではqueueが詰まってジョブが実行され
AWS Lambda CI/CD俺的ベストプラクティス - くりにっき
Lambdaで動くアプリやフレームワークの事例はよく見るのですが、LambdaのCIやCDにしやすさに主眼をおいた紹介はあんまり見ないので現時点での自分のベストプラクティスのメモです tl;dr; このエントリで書いていること Lambdaをデプロイするのに肝になること デプロイしやすさに着眼したフレームワーク紹介 論外 コンソールからアップロードする できなくはないがかなり厳しい Terraform Apex 8/12 17:20追記 実用レベル Serverless Framework AWS SAM native extension問題と戦う Amazon LinuxのEC2インスタンス内でビルドする Amazon Linux互換のDockerイメージを使う Serverless Frameworkのプラグインを使う ライブラリをインストールするジョブとデプロイするジョブを分ける 【
Dependabotの設定ファイルを置くようにした - くりにっき
なにげなくDependabotを見てたらリポジトリに .dependabot/config.yml を置けることを気づいたので置いてみた https://dependabot.com/docs/config-file/ 設定ファイルを置くメリット いつも使ってる設定晒し 解説 default_assignees allowed_updates automerged_updates version_requirement_updates まとめ ちなみに .dependabot/config.yml をコミットしてると設定画面でこんな表示になります 設定ファイルを置くメリット 新しくリポジトリを作ってDependabotを導入する時にボタンをポチらずに済む 別リポジトリから設定ファイルをコピーしてくればいつもの設定が導入できる 設定をgitで履歴管理 いつも使ってる設定晒し Rubyだとこれ
CIマニアから見た各種CIツールの使い所 - くりにっき
社内外でちょいちょい聞かれるのでメモ。 前置き GitHubを使ってる場合 ライブラリを作ってる場合 Travis CIを選択する理由 2020/4/21追記 Travis CIを選択しない理由 アプリを作ってる場合 CircleCIとWerckerの共通点 CircleCIとWerckerの機能差異 GitLabを使ってる場合 GitLab CIの優位点 Jenkinsなどを使った方がいい場合 追記：2018/12/8 前置き 100%自分の主観なので偏ってます SaaSかオンプレならSaaS派。（自分でサーバの面倒身たくない） 自分が使ったことがないものは紹介していません 今回紹介してるTravis CI, CircleCI, Wercker, GitLab CI, Jenkinsに関しては仕事や趣味で各3〜4年くらいは使ってるはず GitHubを使ってる場合 ライブラリを作ってる場合
CircleCI orb Perfect Testing - くりにっき
sue445.hatenablog.com で書いてた 今回作ったorbのインテグレーションテストも頑張ってるのですが、長くなるので別の機会に書こうと思います の件です。 https://github.com/sue445/circleci-ruby-orbs/blob/1.2.0/.circleci/config.yml の解説をします 注）タイトルは半分釣りです tl;dr; orbのテストについて YAMLのシンタックスチェック ローカルテスト インテグレーションテスト 【おまけ】スモークテスト用のブランチを自動で削除する 【おまけ】orbリリース時に自動でgitのtagをpushしたい tl;dr; 何をテストしたいかによって難易度が変わる orbのテストについて https://github.com/CircleCI-Public/config-preview-sdk/blob/
CircleCI 2.1のorbを作って最速で実アプリに投入した - くりにっき
tr;dr; 【前置き】先日の出来事 orbとは 【今回作ったもの】sue445/ruby-orbs モチベーション 準備 使い方 補足 CircleCI 2.0から2.1に移行したPR ついでにHerokuにデプロイするやつもorbに寄せた Before After 補足 post-deploy Context one more thing 追記：2018/11/16 tr;dr; https://circleci.com/orbs/registry/orb/sue445/ruby-orbs https://github.com/sue445/circleci-ruby-orbs 【前置き】先日の出来事 2.1 preview自体は結構前から出ていたのですが、先日正式リリースされました 本日Orbsをリリースしました🥳OrbsはWorkflow以来のメジャーアップデートです。Orbsは
CircleCI 2.1 previewのcommandsが便利だった - くりにっき
https://github.com/CircleCI-Public/config-preview-sdk を見てたら commands が便利そうだったのでためしに個人プロダクトに入れてみた。 github.com 準備 Before (CircleCI 2.0) After (CircleCI 2.1 preview) 所感 作業PR 準備 Advanced Settingsの「Enable build processing (preview)」で有効にしないと使えないので注意 Before (CircleCI 2.0) Ruby製のアプリのCIを構築してると restore_cache でbundle installのキャッシュをリストア bundle install save_cache でキャッシュを保存 というのが頻出すぎてリファクタリングしたかった。 実際に使ってた設定を抜粋
zatsu_monitorという雑な監視ツールを作った - くりにっき
社内LT大会ネタで作ったやつ（第1弾） モチベーション 無いなら作ろう 使い方 ステータスが変わった時だけ投稿 仕様 yamlなので値を継承できるのが嬉しい モチベーション 社内外で公開してる個人アプリをURL監視したかった 社内だとOpenStack、社外だとHerokuに計10個くらい？ HerokuにもRollBar *1 はあるんだけど、たまにDyno（インスタンス）の起動でこけるのは検知できない *2 Mackerelだと社内ツール*3 が監視できない 無いなら作ろう github.com 使い方 雑にyamlを書いて # zatsu_monitor.yml google: type: slack check_url: "https://www.google.com/" api_token: "AAAAAAAA" channel: "#general" user_name: "z
RSpec Performance Turning - くりにっき
社内で開催されたRSpec勉強会テストのパフォーマンスチューニングについて話したので資料を公開してみます。 RSpecの名は冠しているものの他の言語やテスティングフレームワークでも応用できるところがあるかもしれません。 RSpec Performance Turning from sue445 8/3追記：はてブコメント返信 テストのテストにはテスト対象を使えばいいんでしょうか。 場合によりますね。 基本的にはテストコードとテスト対象のプロダクトコードはペアであるはずなので、テストにバグが混入したとしても対応するテスト対象が変更されていなければテストがなんらかの形でエラーになるので、そこで検知できると思います。 テストコードのリファクタリング（共通処理をメソッド抽出など）は、既存のテストが品質を担保してくれてます（グリーンのままであればリファクタリング成功） 0からテスト書く場合でテストの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
