既に幾つかのニュースサイトでは記事が上がっていますが、今週、Linux Foundationの傘下で、CloudBees, Google, Netflixなどをはじめとする幾つかの会社や、Jenkins, Jenkins X, Spinnaker, Tektonの４つのプロジェクトが、「Continuous Delivery Foundation」という新しい財団を発足させました。 CI/CDの世界を標準化？ 新たに発足した組織「Continuous Delivery Foundation」とは (@IT) Linux Foundationが、継続的デリバリーの協業を促進する新ファウンデーションを発表 (時事ドットコムニュース) JenkinsやSpinnakerなどの開発をホストする「Continuous Delivery Foundation」発足。CI/CDの普及とエコシステムの発展
モチベーション 使ってる技術 デプロイ周り https://sue445.github.io/my-ci-badges github.com モチベーション gemやアプリなどを40個くらいメンテしてて一応全てでweekly ビルドを実行してるのですが、CIのバッジが各リポジトリにしか貼っていなくてCIのステータスをまとめて見るためのポータルサイトが欲しかったので作りました。*1 製作時間半日くらい 使ってる技術 Bootstrap v4.0.0-beta いつものようにbootstrap使おうと思ったら4系が出てたので雑に投入 Vue.js 「いつもMithril.js を使ってるのでたまには違うのを使うか」っていう雑な理由でVue.jsを採用 デプロイ周り GitHub Pagesを使ってるのでGitHubにpushするだけ。CIいらずで楽 *1:ビルド結果も個人Slackに全部流して
マサです。 最近、ヌーラボは行動規範をアップデートしましたので、そのへんのお話を。 それなりの規模になってきた企業は、とにかく、企業の目線に比べると些細であろう問題に対して恐ろしく時間を使うことになります。シリル・ノースコート・パーキンソンさんが主張した「組織は些細な物事に対して、不釣り合いなほど重点を置く」という現象。これ、パーキンソンの凡俗法則っていう名前がついているほど、あるあるなケースのようです。 たとえば、FreeBSDの開発メーリングリストで『あなたは数10億ドル規模の原子力発電所の建設の承認を得ることができるけど、あなたが建てたいのがバイク小屋だったら、終わりなき議論になるよ』みたいな投稿がされたらしいのですが、これは、「誰でも出来るようなことは議論が長くなって、理解できない内容に関してはあまり議論されないよ」っていうこと。特にオープンで誰もが情報にタッチできるようなオープン
こんにちは、東京品質保証部の新関です。 2017年に入り、ちょうどテストエンジニアリングチームを設立して一年が経ちました。設立からのテストエンジニアリングチームの活動が、開発組織へどのような影響をもたらしたのか、紹介したいと思います。 テストエンジニアリングチームとは まず、テストエンジニアリングチーム(以下TE)の説明から簡単にさせてください。サイボウズのTEは『枠組みを超えて品質/生産性の向上に貢献する』をミッションに設立した、プログラマーとQAのジョイントチームになります。 テストエンジニアと組織構造 @Cybozu from Jumpei Miyata www.slideshare.net @miyajanの紹介資料にもありますが、2016年1月に3名でキックオフし、テスト自動化の推進を主に行っています。 TE設立背景は紹介資料にある通り、内部環境の変化により、品質保証への要求も変
Post author:sider Post category:Engineering / Other Reading time:3 mins read Post published:2016-01-13 エンジニア x ニッチ(特化)なサービスを調査、「これは流行りそう…!」と思ったサービスを10個ご紹介。 誰もが知っていそうなサービスは含んでません。「俺はエンジニア向けサービス詳しいぜ！」という方も安心して御覧ください。 CI(継続的インテグレーション) DEPLOYBOT デプロイのためだけのCIサービス。デプロイに特化。 リリースノートページやリリースの度にリリース内容をメモする事が出来る機能、デプロイのトリガーを手動で実行することが出来る「デプロイ」ボタン機能などがある。 1リポジトリの「Hobby」ユースであれば永年無料。 deploybot.com Codecov コードのテ
Gitlab + Jenkins があまりグッとこなかったので，Gitlab + Gitlab CI をためしてみた．結論から言えば，Gitlab + Jenkins より良いと思う． Docker 上に準備 やることは Gitlab コンテナを動かす Gitlab CI コンテナを動かす Gitlab Runner コンテナを動かす OSX 環境でためしたので， $ docker-machine ip default 192.168.99.100 文中の192.168.99.100 とポートは適宜読み替えてください． 1. Gitlab コンテナを動かす $ curl https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml > gitlab.yml $ docker-compo
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
(English version here) 技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。 紹介 他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。 なぜ「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。pull requestが出る度に、Jenkinsがそのpull requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。 現時点でDo
忘れないようにメモ。 発表時と違う点は エンジニアの総数修正 IAMがダブってた PRのReviewerについて格助詞の使い方を間違えていたのを修正。 -> 「を」と「の」
約800サイトが導入する「Scutum」のビットフォレストが、3ステップで継続的セキュリティテストができる「VAddy」をリリース セキュリティの専門知識がなくても使えるセキュリティサービスが、昨年2014年10月にリリースされた「VAddy（バディ）」です。既に、じげん など複数の企業が導入していて、今年3月を目処にグローバル版のリリースも予定しています。Bitforest（ビットフォレスト）でVAddyを開発する市川快さん、佐藤匡さん、広報を担当している西野勝也さんにお話を伺いました。 たった3ステップで実現する継続的セキュリティテスト VAddyは、Webアプリケーション開発の初期段階からリリース後まで、全てのフェーズで継続的なセキュリティテストの実施を可能にしてくれるクラウド型サービスです。昨今、開発イテレーションのスピードは増す一方ですが、従来型の脆弱性診断サービスの適用は難しく
タイトルの通りだけど MySQL Casual Talks vol.7でお話してきた。 MySQLのbackupはみんな取ってると思うけどそのBackupって本当にRestore出来るのかなーという不安からRestoreを検証してくれる仕組みを作ってみたというお話 発表資料はこれ 実は発表の二日前にようやくちゃんと全部のjobが綺麗に動いたんだけど、 何故かその段階で、もう大丈夫っしょ！(・。・)となってしまい、 実際に全部のjobを連結させて一連の流れが見えるようになったのは、 なんと発表当日会場入りの30分前という体たらくっぷり。 なので、資料の途中に書いてある実際の運用ではとかのくだりは、あくまでもそういう予定である。 みたいなかんじになってしまった。なんか今思うと詐欺みたいだなｗ 発表にあたって 実は人前で何かを発表するみたいな経験に乏しく、 発表当日は緊張しすぎて雨に濡れた子犬み
Werckerの仕組み，独自のboxとstepのつくりかた WerckerはTravisCIやDrone.ioのようなCI-as-a-Serviceのひとつ．GitHubへのコードのPushをフックしてアプリケーションのテスト，ビルド，デプロイを行うことができる． Werckerは，TravisCIのように，レポジトリのルートにwercker.ymlを準備し，そこに記述された実行環境と実行コマンドをもとにテスト/ビルドを走らせる． Werckerには，その実行環境をbox，実行コマンド（の集合）をstepとして自作し，あらかじめWercker Directoryに登録しておくことで，様々なテストからそれらを呼び出して使うという仕組みがある．実際，Werkcerで標準とされているboxやstepも同様の仕組みで作成されている（wercker · GitHub）． 今回，WerkcerでのGo
Do you want everything set up for you instantly, or do you want to customize your environment and your workflow? CloudBees CodeShip lets the developer pick the path that’s best for them, to maximize productivity and let teams evolve over time. You can get your builds and deployments working in less than five minutes with CloudBees CodeShip’s turnkey environment and simple UI. From there, you can e
This documentation site is Open Source. The README in our Git repository explains how to contribute. Travis CI relies on Open Source licensing information. Travis CI Build Configuration and Settings # Builds on Travis CI are configured mostly through the build configuration stored in the file .travis.yml in your repository. This allows your configuration to be version-controlled and flexible. For
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く