MyBatis MigrationsとBambooとSchemaSpyでデータベースの構成を管理する - bluebird
このエントリーは、ゆかむアドベントカレンダー - ゆかむ | Doorkeeperの7日目エントリーです。 はじめまして。@setoazusa です。こんなハンドルですが、男性です。 都内のSIerで、TDDの導入や、DevOpsの推進、プロジェクトメンバーのフォローなどを仕事にしています。 IT技術者のコミュニティでは、TDDBCなどのコミュニティなどを中心に活動しています。よろしくお願いします。 ゆかむさんとは、第2回 ゆかむ勉強会 - connpassで、「CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化」というお題で話をさせていただきました。 CIサーバーとSchemaSpyでデータベースのドキュメント作成を自動化 from Hiroyuki Ohnaka 今日は、その話の続きで、データベースのスキーマ管理のために、ツール同士をどう連携させているかという話を
Jenkins+GradleでJavaのCIのための基本build.gradle設定 (JUnit,PMD,FindBugs,CPD,JaCoCo) - Qiita
Jenkins+GradleでJavaのCIのための基本build.gradle設定 (JUnit,PMD,FindBugs,CPD,JaCoCo)JavaJenkinsgradlePMDFindBugs 私的Java開発をJenkinsでCIするためのbuild.gradleとJenkinsの設定です。要不要に応じて書き換えたり足したりが必要です。特にチェックルール。 環境 Java 1.7 Groovy 1.8.6 Ant 1.9.2 Ivy 2.2.0 Gradle 1.11 Mac OS X 10.9.2 全体の流れ Jenkinsに必要なプラグインをインストール GradleでFindBugs, PMD, CPDを実行するようbuild.gradleを作成 Eclipseでは Jenkinsにいれるプラグイン Gradle plugin - jenkins+gradle連携 Fi
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
CIについてのおさらい - ワザノバ | wazanova.jp
CIについては、 CIに興味がある会社は多いが、 バックアップをとってない バックアップをとっていても手順書がない システム監視してない 退職者がでても本番用のパスワードを変えてない サーバ設定管理をしてない システムをスケールさせる段取りがついてない サーバ交換の手順が決まってない など、まともなシステム運用環境が用意されてない事例が散見される。最初からHerokuやPaaSに任せている会社であればよいが、そうでなければ基本的なことの整備は大切。まずは、Ansible / Puppet / Chef / SaltStackなどでの設定管理から手をつけてみればよいのでは。 という意見もあるようですが、「CIとは何か？」については、やはりThoughtWorksのサイトが一番簡潔によくまとまってるようです。 Integrate at least daily コードを1日数回共有のreposi
Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー - naoyaのはてなダイアリー
先日プレスリリースが出たのですが、KAIZEN platform という会社で技術顧問などをやっています。それから、一昨日自分も出たWebアプリケーション開発に関する勉強会 (資料) を開いたじげんという会社でも少し前から同じように顧問のような形で携わっています。 自分が関わっている会社のPRも含めて、すこし、2013年現在のWebサービス開発の現場感、やり方みたいなものを書いてみたいと思う。ただ、自分の利益があるところの話だけではフェアではないので、Webエンジニアならよく知っているであろう Qiita を運営しているインクリメンツの様子も合わせて紹介する。 KAIZEN platform KAIZEN platform が提供しているサービスは planBCD という A/B テストの SaaS で、Webサイトのコンバージョンだとかを画面の構成要素を変えて効果測定したいとか、そういう
なぜリリース頻度を上げるのか
サービスのリリースで書いたようにネットのサービスを提供している企業は新バージョンのリリースの頻度を上げるよう常に努力しています。 リリースの頻度を上げる理由は、サービス開発の方向の軌道修正を細かく行いたいからです。少しずつサービスを改良し、その改良がユーザーにどのように受け入れられたかという反応を元に将来の開発を行っていきます。このフィードバックサイクルを短くすることによりこまめな軌道修正が可能になります。 リリース頻度が低く、リリースサイクルが長いと、その期間に加えられた変更の数が多くなり それぞれのリリースでの変更量が大きくなります。変更が多い分、リリース後の不具合発生の可能性が高くなります。また、リリース後の障害発生時の問題の切り分けも難しくなります。小さなリリースを頻繁に行うことにより、一歩一歩問題がないことを確認して次の一歩を踏み出すように、よりリスクの少ないリリースが可能になり
DevOpsの今とこれから #init_devops
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
Jenkins で静的解析のグラフを作るとコードを読まなくてもソフトウェアの品質が分かって面白い - おともだちティータイム
細かく書きたいけど、とりあえずメモだけ。 ステップ数が増ている なんらかの開発が行なわれている ステップ数が減っている リファクタリングが行なわれている? 単に仕様落ちしたコードが削除された可能性もある テストカバレッジが下がる テストが書かれていない ... ステップ数が増えている場合 テストが減っている ... ステップ数が変わらない場合 FindBugs 、 PMD 、 Android Lint の警告数が増えている 品質の低下、レビューが正しく行なわれていない CPD 警告数が増えている 品質の低下、レビューが正しく行なわれていない そろそろリファクタリングしたほうがいい Checkstyle 警告数が増えている 品質の低下、レビューが正しく行なわれていない Jenkins で継続的にビルドしたり、テストを行なうのは言うまでもなく大切だけど、こういった静的解析の数値をグラフ化してい
プライベートリポジトリを激安にCI出来るCircle CIが凄い。 - Qiita
@takehiro に教えて貰ったCircle CIを使ってみるともの凄く良くて、とてもお勧めなので記事を書きました！ Circle CIって何？ Travis CIと同機能でWebでのUIが若干違うサービスです。 CIとしての仕事はきちんと行えます。 Circle CIの使い方 https://circleci.com/ にアクセスします。 Githubアカウントでサインアップを行います。 画面に従って進むとプロジェクトをfollowする画面が表示されます。 CIしたいプロジェクトをfollow後、"Done Managing Repos"をクリックします。 ここでは"camelmasa/spree"を選択します。 するとfollowしたプロジェクト一覧のテスト結果の画面が表示される様になります。 これでCIが出来る環境が整いました！ 後はgithubにpushする毎にCIが実行される様
『Jenkinsで定期実行するJobを管理したほうが良い３つの理由』
定期実行って、Cronを使ってやるのが一般的ですよね。 エンタープライズシステムだとJP1とか使って管理したりしますが、 それJenkinsで良くない？ というわけで考えて見ました。なんでJenkinsがいいのか。 メリット（cronとの比較）① SVNなどのSCMとの連携が可能 ② メール等のアラートが可能 ③ 実行履歴の確認が容易 デメリット① Jenkinsが落ちたら動かない ただこれはJenkinsの監視やバックアップである程度回避できます。 またJP1 などは大変高価なので、無償で使えるのは嬉しいですね！実際にやってみたまずはSVNに適当なプロジェクトを作って適当なShellスクリプトをコミットしてみます。 SVNはファイル単位でのチェックアウトができないのでGitで管理したほうがいいのかもしれません。 Shellスクリプトは終了コードを明示的に0と書いたほうが良いでしょう。 J
超速で開発・リリースするための6つのこと - Cybozu Inside Out | サイボウズエンジニアのブログ
「サイボウズ・アドベントカレンダー」の8日目です。ちょうど真ん中まできました（これまでの記事一覧）。 こんにちは。kintone 開発チームの刈川です。いきなりですが、皆さんはどのくらいの頻度でアプリやサービスをリリースしていますか？ 1週間？ 1ヶ月？ 1年？ 規模によると思いますがクラウドサービスではリリースのスピードが大事です。せっかくいいアイデアを思いついたのに、それを実現するまでに果てしない時間と労力がかかるとしたら…。ユーザの意見を取り入れるまでに半年も一年もかかっていたのでは、ユーザは他サービスに移ってしまうかもしれません。そこで今回は、私たち kintone チームが取り組んでいる「スピーディな開発・リリース」のための手法を簡単に紹介したいと思います。 アイデアを形にする アイデアというのは形にするまでがゴールです。開発現場ではこのことをリリースと呼び、リリースをするまでに
Jenkinsとhadoopを利用した継続的データ解析環境の構築
2. Meta Information • 2006.4 – 2012.3 – Keio University • Artificial Intelligence, Semantic Web, Ontology Engineering • 2011.2 – 2012.3 – CTO at Trippiece, Inc. • Software Engineering • 2012.4 – – Engineer at adingo, Inc. • Data Analysis, Operation Engineering twitter: @suzu_v http://blog.kentasuzuki.net
あなたの現場を「アジャイル」に変えたいとき、たどる道筋は2つある
国内でのアジャイル開発の普及と共に、アジャイルという言葉が指す内容にも広がりがでてきました。同じ「アジャイル」という言葉を用いたとしても、それが何を指すのかを注意深く理解する必要が出てきたといってもいいでしょう。 そんな現状を、アジャイル開発の第一人者である平鍋健児氏がブログ「An Agile Way」にポストしたエントリ「アジャイルの「ライトウィング」と「レフトウィング」」で、非常に分かりやすい図と共に整理しています。以下に許可を得てその主な部分を転載します。 アジャイルの「ライトウィング」と「レフトウィング」 アジャイルの認知が進むにつれて、アジャイルという言葉がどんどん広がっている。アジャイル、という言葉の中にはいろんな要素が入っていることが分かる。もっと大きなものは、CI（継続的インテグレーション）を中核とする技術的なプラクティス群と、スクラムプロセスフレームワークのような、人と人
Developer summit continuous deliveryとjenkins
2. 川口耕介って誰？ • Jenkinsクリエイター＆プロジェクトリー ド • アーキテクト @ CloudBees • その前は… – RELAX – JAXB, JAX-WS, JAXP等 @ Sun Microsystems – GlassFish v3のモジュールレイヤの一部など – FreeTrain ©2010 CloudBees, Inc. All Rights 2 Reserved 3. jenkins-ci.org • JavaによるCIサーバ/OSS • 7年位やっている • 使うのが簡単 • プラグインによる機能拡張 – 現在 450+ • 世界中で広く普及 – インストールベース: 31K+ ©2010 CloudBees, Inc. All Rights 3 Reserved
JIRA、Jenkins、GitHubで始めるオープンソース #jiraadvent – yusuke.blog
・JIRA Advent Calendarの最終日担当です。 趣味でなんとなく作ったものの放置してしまっているアプリケーション、ユーティリティ、ライブラリはありませんか？ オープンソースソフトウェアにしてしまいましょう！ もちろん懸念はあるかもしれません、例えば： ・オープンソースってやってみたいけど人に見せられるほどキレイなコード書ける自信がない じゃぁいつやるの？ 今感じる範囲でキレイなコードにして公開してみたら？ ・同じようなコードは他にもあるし・・・ 既存のコードで歯がゆいところがあったから書いたんじゃないの？ 地球に70億人もいるんだから同じように歯がゆさを感じている人が1人や2人はきっといるはず。 ・オープンソースにしたら盗まれちゃう！ 死蔵してたらすぐに、またはいずれ陳腐化して新規性のないコードにきっとなります。 盗まれて困るようなコードだったらとっとと起業してビジネスにした
【資料公開】ワンクリックデプロイ勉強会
2011年12月20日に品川の日本マイクロソフト本社をお借りして、ワンクリックデプロイ勉強会を開催しました。 当初内輪でやろうと思っていたのですが多くの方にご参加いただきありがとうございました。 また、もろもろセッティング頂いた@katzchangと日本マイクロソフトの長沢さんありがとうございました。 以下にセッション資料を公開します。 例によって短文での感想を。 セッション開始前にちゃんとRed Bullを飲んでおいたので元気だった最初の会場へのヒアリングで既にワンクリックデプロイをしている人がいるか調査したところいなかった。まぁWebサービス系でやっているところは増えては来ているもののまだ定着フェーズではなさそうな感じユニットテストやJenkinsはかなりの現場で使われている個人的な今日の名言は、「障害発生時に１日でリリースできるなら、普段のリリースも１日にできるはずだ」というやつ。物
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Netty.news: New build server, powered by Clinker
3 reasons to choose Bamboo | Valiantys Blog
安全な継続的デプロイメントのための知覚的テスト
Continuous Integration and Delivery - CircleCI
