仕事を効率化するデプロイツールを作った - 技術探し
仕事の開発環境改善のために欲しかったので金曜日からコツコツ作っていたアプリケーションを紹介します。 github.com 目的 CIが走るとstorybookやフロントエンドの成果物などの静的ファイルを自動的にアップロードして、PRでのレビューコストを下げるのが目的です。 PRでのレビュー時にCSSの変更などローカルに落として確認するほどでもないものを落としてビルドするのは時間の無駄だと思っています。 また、特にstorybookはデザイナさんと共有することが多いので、常に見れるところにあってほしいなって思っています。 gh-pagesでもいいけどコミットが面倒なのと、複数並列でアップロードできないのが問題です。 つまりmasterのしか置けず、今自分が作業している状態を見せたい時の共有が大変です。 このツールと同じでS3にデプロイするツールは知ってますが、カスタマイズしたいのと自分のサー
Dockerで簡単なCICDツールチェーンを構築 - Qiita
前回の投稿で作った環境にDockerコンテナでツールチェーンを作っていく。やってみるとDockerは偉いとつくづく思う。 GitLab CentOSでコマンド実行。 # docker pull gitlab/gitlab-ce:latest #docker run --detach --publish 442:442 --publish 80:80 --name gitlab gitlab/gitlab-ce:latest 母艦のブラウザでCentOSのポート80にアクセス、rootのパスワードを設定 Jenkins kubectlと、(後で使うかどうかも定かではないが)ansibleを仕込んだJenkinsコンテナを立ち上げておくことにした。CentOSで作業。あ、maven… 必要になったら入れよう。 作業ディレクトリを作成 # mkdir <WORK>; cd <WORK> # cu
Ukigumo - Yet another continuous testing tool - tokuhirom's blog
http://github.com/ukigumo/ なんか、お気軽につかえて、カスタマイズが容易で、お気楽な continuous testing を support する tool がほしかったので、ちょろっとかいた。 ターゲットは自社サービスの web アプリケーションです。 ベーシックなクラサバ構成となっています。サーバー側は簡単な Web UI と、RPC を提供しているだけで、ごくシンプルです。サーバー側とクライアント側には依存関係はありません。クライアント側はプラガブルな構成となっていて、誰でも簡単にいじれます。 クライアント側は Plagger 風にしようとおもったんですけど、Plagger 風にするといかんせんおおげさになりすぎるので、ライブラリとしての提供にとどめました。べろっとよんだら普通に理解できます。コードをシンプルにするために忌み嫌われがちな Mouse を採用
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
What are the best Continuous Integration Tools?
