古橋貞之さんインタビュー - Tokyo RubyKaigi 11
17:55 Keynote 分散ワークフローエンジン『Digdag』の実装 ワークフローエンジンは、依存関係のある複数のタスクを実行するツールです。古典的なMakefileを始め、Python製のLuigi、商用のJP1/AJS3など、様々な実装があります。Digdagは、現在活発に開発が進んでいる新しいワークフローエンジンです。このセッションでは、ツリー構造を持つワークフローの状態遷移を効率的に実行する手法、ワークフローの実行状態の永続化と分散実行、タスクスケジューラ、Dockerによるサンドボックス化など、その実装手法を紹介しながらワークフローエンジンの構成技術について解説します。 必要となる知識 SQLの基本的な知識と、Rubyのリフレクション、オプティマイザなどの知識があると、より楽しめると思います。 古橋 貞之 Treasure Data, Inc. Founder & Soft
Treasure Data社のOSSワークフローエンジン『Digdag』を試してみた #digdag | DevelopersIO
Digdag が Apache License 2.0 の元でオープンソース化されましたよ！ さぁ試すんだ…！ 今すぐにでも！ https://t.co/Uzc4a5GLCe ドキュメント：https://t.co/PF8wy5KHln — Sadayuki Furuhashi (@frsyuki) 2016年6月15日 という訳で試してみました。注目度の高かったワークフローエンジン『Digdag』がついにOSS化されました！Githubリポジトリ及びドキュメントは以下となります。 treasure-data/digdag: Workload Automation System Getting started — Digdag 0.8 documentation 目次 インストール 環境の準備 Digdagのインストール実施 その他ドキュメントの内容について Digdagサンプルワークフロ
Ruby製のシンプルなワークフローエンジンRukawaの紹介 - Qiita
Bigqueryを使ったバッチジョブを色々と実行しているのですが、Rakeで複雑な依存関係を管理したり、並列実行させたりするのが辛くなってきたのでRukawaというワークフローエンジンを自作しました。 自作したのは、RailsプロダクトにAirflowとかLuigiとかAzkabanとか入れるにはちょっと重厚過ぎる感じだったのと、Rubyで書ける方が楽で良いやという理由からです。 RukawaとはRUby KAntan Workflow Assistantの略です(後付け) (本当はミッチーとか水戸の方が好きなんだけど良い名前が浮かばなかった) 実際は、並列実行を可能にして書き方を変えてみたRakeとそんなに大差無い。 Rukawaの機能 ジョブの定義 まず実行したい処理をジョブクラスに記述します。 module ExecuteLog def self.store @store ||= {
Workflow Engine をつくろう！ Part 1（Task の依存関係の解決） - Qiita
Part 1 Task の依存関係の解決 Part 2 Workflow の冪等性 Part 3 Task 間でのデータのやり取り Part 4 Task の並列実行 Workflow Engine って何？ Workflow Engine と言っても多機能なものから、シンプルなものまで様々なものがあります。そこで、主旨がぶれないように、この記事での Workflow Engine は、以下の要件を満たすソフトウェアとします。 Workflow Engine とは、依存関係のある複数の Task を、意図した順番通りに実行するもの この記事では、この要件を満たす Workflow Engine を Ruby でつくる方法について解説します。 依存関係を記述する 依存関係を解決するコードを書く前に、依存関係を記述する方法をまず決めましょう。 依存関係を記述するには、luigi のように Ta
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
