社内 apt リポジトリの運用と deb パッケージビルドの話 - クックパッド開発者ブログ
id:sora_h です。今回はクックパッドの社内 apt リポジトリ管理・deb パッケージビルド・リリースフローについて紹介します。 クックパッドではいままで CentOS 6 を利用していましたが、最近は Ubuntu への移行を進めています。現在は CentOS / Ubuntu 両方が共存したインフラになっています。 CentOS では社内に yum リポジトリを置き、本家リポジトリから消えてしまったパッケージや、独自でビルドしたパッケージのホストを行っていました。Ubuntu 導入以降も同様に、社内 apt リポジトリを設置し、必要があれば独自でパッケージをビルドすることにしました。具体的には、わたしは ruby2.1 パッケージや ruby2.2 パッケージをメンテナンスしています。 (なお、わたしは rpmspec および ebuild の方が慣れていて、未だ deb パッ
Cask - naoyaのはてなダイアリー
昨年 ELPA で elisp を管理 - naoyaのはてなダイアリー に書いたとおり、昨今は Emacs にもパッケージ管理システムが搭載されいて、どこからか elisp をコピペしてきてその後管理できなくなる･･･みたいなことはなくなった。 ただ、じゃあ ELPA で全て解決したかというとそんなことはなくて、ELPA はパッケージのインストール自体は簡単にしてくれるけれども、それだけだった。 elisp の管理も Bundler のように入れたいパッケージ一覧を書いて bundle install すれば全部まとめて入るみたいな、そういうのが欲しい･･･と常々思っていた。 と思っていたら、Cask というのを見つけた。これがずばりそのものだった。 (source gnu) (source melpa) (source marmalade) (depends-on "ag") (dep
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
