We’ve been quiet on the blog for a while, but pretty busy behind the scenes for the last couple of weeks. There’s lots going on, but what I’m working on specifically is a new deployment model for Resin 4. In addition to our current file system based hot-deploy, we’re now adding a deploy model based on Git. We introduced this in Resin 4.0.0 and 4.0.1, but we started exploring the benefits of Git repositories and realized that we have the ability to do some really powerful things like sophisticated application versioning and rolling out applications in stages. I’ll show you the new model and give a preview of how you can use it in upcoming versions of Resin.

(more…)

For the Resin 4.0 remote deployment, I wanted some key features: incremental updates, transactional updates, reliable replication, manageability, and solid performance. It’s taken several months of toying with alternate architectures until the current design came together. At the core of the deployment architecture is the .git source code repository.

• atomic updates
• consistent file store - no broken updates
• independent - multiple writers and readers avoid seeing partial updates
• durable store to the filesystem (and replicated)
• incremental updates only of changed files

The key insight in the .git design is using a hash to identify versioned files. The hash design solves the transactional problem by treating files as immortal, immutable, written-in-stone documents.

(more…)