[Devops] May meeting
Maciej Pasternacki
maciej at pasternacki.net
Wed May 30 01:35:26 CEST 2012
Hi,
Materials & links from today's meetup:
- Code snippets with comments for the build system: https://gist.github.com/2823575
- Vagrant, a convenient command-line tool for running VirtualBox virtual machines (VMs): http://vagrantup.com/
- FPM (Effing Package Management), the main actor: https://github.com/jordansissel/fpm/
- Buildbot, the continuous integration server: http://trac.buildbot.net/ (alternative for open source, Travis CI: http://travis-ci.org/)
- Articles about setting up Buildbot by Jacob Kaplan-Moss, creator of Django:
- Part 1, http://jacobian.org/writing/buildbot/ci-is-hard/
- Part 2, http://jacobian.org/writing/buildbot/configuration-and-architecture/
- Runit, a sane reimplementation of Dan J. Bernstein's daemontools under BSD-like license. A tool for managing long-running services (I'd say "daemons", but they don't daemonize – they are managed by runit when running in the foreground): http://smarden.org/runit/
- LXC - Linux Containers, a lightweight userspace virtualization for Linux (may be used for real clean builds or for testing the packages): http://lxc.sourceforge.net/
- The Debian Policy Manual: http://www.debian.org/doc/debian-policy/index.html#contents
FPM is a command-line tool that converts between different package formats (from: local directory, ruby gem, php pear, python module, node.js npm package, deb, rpm; to: local directory, deb, rpm, solaris, tar). The "local directory" pseudo-format allows for easy creation of quick-and-dirty packages that Just Work, short-circuiting all the layers from the Debian Policy Manual all the way up to dh_make with one quick script call. FPM doesn't care about actually building your stuff (as in: unpacking, configuring, compiling, etc). It just takes directory you put it into, and turns it into a package. To prepare the compiled files and put them in the right place first is your job. So is specifying the dependencies - there are no automatic dependencies on dynamically linked libraries.
Workflow for the continuous integration using bits & pieces from the gist:
- On developer's workstation, "vagrant up" command brings up new VirtualBox VM with clean Debian and sets up a clone of the "packages" repository with a local branch
- "vagrant ssh" to the VM, go to the packages repo, prepare or modify new package, test it
- "git push" from the VM to the "develop" branch on the host server
- "git pull . develop" on the host server's master branch to merge
- "git push" to central git repo
- buildbot (continuous integration server) picks up the commit
- buildbot builds changed package and adds it to the apt repo
- new package is available to clients via apt-get within minutes from the push.
Misc links:
Check_MK for Nagios: http://mathias-kettner.de/check_mk.html
Next meetup is on June 19th - no topic yet. If anyone has something to show / say, it's a good time for that!
See you next month!
-- M
On May 29, 2012, at 18:42 , Maciej Pasternacki wrote:
> Hey,
>
> I'm running late and just got into a monster queue. Will be at the Lab 20-30 minutes after 7. Sorry about that.
>
> --M
>
> On 21 May 2012, at 18:21, Michael Prokop <mika at grml.org> wrote:
>
>> * Maciej Pasternacki [Mon May 21, 2012 at 05:19:04PM +0200]:
>>> There will be slides / code snippets :)
>>
>> Great, looking forward :)
>>
>> I'm doing lots of Debian packaging continuous integration work
>> (mostly based on https://github.com/mika/jenkins-debian-glue) and
>> also did some work with fpm, would love to chat with you about this
>> topic, so feel free to drop me a note via irc, jabber, mail,... :)
>>
>> regards,
>> -mika-
>> _______________________________________________
>> Devops mailing list
>> Devops at lists.metalab.at
>> https://lists.metalab.at/mailman/listinfo/devops
More information about the Devops
mailing list