Simplify your code review process

Managing a repository can require tedious administrative work, and as pull requests increase, it becomes even more complex. Today’s review flow lacks important visible information that leads to serious management issues.

Rivi is an innovative tool that automates repository management. 

I've recently launched a hosted Rivi service (at http://rivi-cm.org ). 

Simply by adding a rules file (YAML) to your repositories and you can take advantage of the service.

Using crane for github-like docker development

Note The version of crane described below is a modified one. Find it on my github fork.

If you’re custom to working with github that you’ll recognize the following flow:

1. You fork a repo (e.g. user/foo)
2. You commit and push code to your fork (e.g. bivas/foo)
3. You create a pull request (PR) to merge your changes with original repo.

This approach is usually referred to as upstream remote and branching model is taken from git flow.

The docker flow problem

When working with docker, you pull and push images to a registry. Usually, when using your own registry, your push, pull, tag, build cycle might get messy.

1. You pull company/foo from registry.company.co
2. The pulled imaged is now locally tagged as registry.company.co/company/foo
3. You write a Dockerfile to build a dependent image:
   a. Start with FROM company/foo ?
   b. Start with FROM registry.company.co/company/foo?
4. So you decide to tag the pulled image as company/foo Remember: You can’t use ARG in FROM directive, so your registry prefix is there for good (or until refactored)
5. Completed your local tests and you wish to push. Again, your tag your image and push it as registry.company.co/company/foo

Why can’t we simply do - pull, build, and push? Let someone else deal with the registry and tagging.

The crane flow

So we have our registry at registry.company.co, our images are prefixed as company and all our Dockerfiles begin with something like company/foo. We extended crane to support our flow of pull (from official registry), build (locally on developer workspace, and push (to a user registry for backup). The entire flow keeps the original image name as company/foo but knows when to change tags to support other flows.
Here’s an example crane.yaml file:

containers:
  os:
    image: company/os
    build:
      context: os/
    pull:
      registry: ${DOCKER_REGISTRY}
 etcd:
     image: coreos/etcd:2
     push:
       skip: true
 service:
     image: company/service
     build:
       context: service/
     pull:
       registry: registry.company.co
     push:
      registry: registry.${USER}.company.co
      override_user: ${USER}

The added directives:

• pull.registry = which registry to pullfrom
  
  • crane will pull from registry.company.co/company/foo and locally tag it as company/foo
• pull.override_user = which user to pull as
  
  • crane will pull the specified image as ${USER}/foo and locally tag it as company/foo (useful when testing against your version of the container stack.
• push.registry = which registry to push to
  
  • crane will push to registry.company.co/company/foo the image locally tagged as company/foo
• push.override_user= which user to push as
  
  • crane will push the specified image as ${USER}/foo the image locally tagged as company/foo (useful to backup your images in registry)
• push.skip = skip the image when attempting push (useful when dealing with community images)

Now, a developer can easily work with FROM company/foo directive without dealing with re-tag. She can also modify company/foo and keep a backups without the need to re-tag the entire images stack.
We have a github-like development cycle of “forking” (pull) the official registry, pushing images to your private registry for development and backup (push). Once the developer is satisfied with the modifications - she creates a normal pull request to the modified Dockerfile.

Event Driven Programming With Event Roaster

Often, in a multi layered, structured application it is sometimes required to notify several services on a system state change. Such change could be of some user interaction with our application, exception thrown from a specific layer or new client registered with our publishing service. These operations can be handled in a variety of paradigms, but for today's lesson: Event Driven Programming.


Recently I faced a problem with our ever growing application of knowing of a network topology change and notify several modules. The initial approach we took was to send important events to a centralize service, which knows almost the entire application structure, that can modify modules state based on the called method. Over time this service got larger and larger, complexity level rose and the maintainability efforts went to the roof. Searching for a suitable solution I broke the behavior to small strategy methods to which I could call from the original method. These strategies are actually event handlers for the state change. Looking around for event handling framework that will suite my needs I came across GWT's HandlerManager, Java's beans implementation, EventBus, ELF and even SpringSource event multi caster. Most, if not all of the above frameworks follow the same guidelines and principals with their provided solution, some are a lot easier to configure than other but what most of them lack is the (poor) support of configuration by annotations.

That's where my github.com account went in handy - I decided to write an event handling framework of my own. Named the project - Event Roaster. The framework is fully annotation configured and if you're working with IoC container like Spring it even provides you with EventServiceFactoryBean. So, here's what you need  to know before you can start working with it:



The snippet above demonstrates how simple the configuration really is and layout for event publishing and handling. Objects you wish to pass around as events are annotated with @Event (no need to implement anything, any object will do) and handler methods are annotated with @EventHandler, each method declaring which event it handles. Handlers can set their priority when called and (future versions will include the ability to) block further event processing. Publishing (a.k.a Firing) an event is as simple as calling the fire event in a matching event service. The event broadcasting is done asynchronous using a multi-threaded executor service. That's all there is to it, implement your handling methods and you're good to go.

Event Roaster is an open source project and as such it requires some attention and assistance by its users and contributers. Future versions are waiting release to Maven's Central repository using Sonatype OSS repository (project can't go to Central unless one of its dependency will move to Central as well). Feedback, feature requests and any general assistance will be appreciated.