Two Git Branching Models

In current projects, we tend to float between two branching models depending on the requirements of the customer / project and the planned deployment process.

git-flow

This was previously known as A successful Git branching model with an extremely detailed overview and instructions here. It has since spawned a project to help make using this model easier – git-flow.

This is a great branching model for a team of people who work towards creating planned versioned deployments (whether it be time based such as every second Tuesday, or milestone based).

In essence, this model uses two main branches:

  • origin/master – the main branch where the source code of HEAD always reflects aproduction-ready state.
  • origin/develop - where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.

Then developers create supporting branches as part of their development process:

  • feature branches – branched off origin/develop for active development of a new feature / enhancement;
  • hotfix branches – a branch off origin/master to apply a critical fix to production code;
  • release branches – short lived branches off origin/develop which are used for final testing and patched before being merged to origin/master.

The model works very well in practice and the above linked document is a excellent read on Git branching practices in general as well as git-flow in particular.

Github Flow

This is the model used at Github and discussed by Github developer Scott Chacon here.

This is suited for projects that deploy continuously rather than around the concept of releases and so it’s less constrained than git-flow. These are two very different models and Scott puts forth his arguments in favour of the Github model in his post linked above.

In essence, Github flow works as follows:

  • origin/master is always deployable. Always.
  • Similarly to git-flow, new features are done in their own branch – but off of origin/master in this case.
  • Now, when you believe your new feature is complete, a merge request is opened so someone else can review and check your work. This is the QA process.
  • Once someone else signs off, you merge back into origin/master.
  • This is now deployable and can and will be deployed at anytime.

 

Specifying Specific SSH Keys for Git Remotes

When using Git via SSH with services such as GitHub and Gitorious, it can be useful to use specific / different ssh keys than your default.

This is accomplished with an entry such as the following in your ~/.ssh/config:

Host some-alias
    IdentityFile /home/username/.ssh/id_rsa-some-alias
    IdentitiesOnly yes
    HostName git.example.com
    User git

You then specify this remote as follows in .git/config:

url = some-alias:project/repository.git

Monitoring Asterisk via SNMP (with OSS_SNMP)

Over on the company blog, we just announced that we committed a complete Asterisk MIB implementation to OSS_SNMP in addition to a proof of concept Asterisk wallboard to NOCtools which includes active channels, uptime, version information and more.

Full details are on the company post but here’s a snippet of how easy it is to query Asterisk over SNMP:

 $host = new \OSS_SNMP\SNMP( $asteriskIP, $community );
 echo "Asterisk version: " . $host->useAsterisk()->version();
 echo "Active calls: " . $host->useAsterisk()->callsActive();
 echo "Calls processed: " . $host->useAsterisk()->callsProcessed();

And here’s a screenshot of the proof of concept Asterisk wallboard:

[NOCtools Asterisk Wallboard]
NOCtools – Asterisk Wallboard

NOCtools – A Mixed Bag of Tools and Utilities for NOC Engineers

NOCtools is a mixed bag of tools and utilities that are useful for NOC engineers. This project originally started out as a way to highlight and utilise our OSS_SNMP library (a PHP SNMP library for people who hate SNMP).

It since grew into a way to graphically present information on network topology that is normally difficult and cumbersome to do by logging into individual devices. Such information includes a discovered L2 topology by CDP, using this to present rapid-PVST port roles and so forth.

From the company blog:

Today, we are introducing NOCtools which uses this library to provide a number of useful tools including:

  • CDP Neighbours: for a given CDP enabled device, display its CDP neighbours with information and also a graph showing connected ports.
  • CDP L2 Topology: graph the layer 2 network topology based on a recursive crawl of CDP neighbours.
  • RSTP Topology & Port Roles: similar to CDP L2 Topology above but this takes a specific VLAN and identifies and graphs Per-VLAN Spanning Tree port roles.
  • Per-VLAN RSTP Port Roles: a tool that will display the per-VLAN Rapid STP port roles for a given VLAN (or for all VLANs) on a device.
  • Inter-Device VLAN Comparison: a tool that will compare VLANs available (and their respective names) across selected devices allowing you to ensure consistency as well as perform simple security audits.

Follow the links about for screen shots and more details. We are releasing this under a GNU GPL license in the hope that the wider networking community will benefit from them.

A PHP SNMP Library for People Who HATE SNMP, MIBs and OIDs!

I hate SNMP! But I have to use it on a daily basis with my company, Open Solutions.

Don’t get me wrong, it’s an essential tool in the trade of network engineering but it’s also a serious PITA. Finding MIBs, OIBs, making them work, translating them, cross-vendor translations, etc, blah, blah. And then, when you do find what you need, you’ll have forgotten it months later when you need it again.

Anyway, while trying to create some automatic L2 topology graphing tools (via Cisco/Foundry Discovery Protocol for example) and also some per VLAN RSTP tools to show port states, I started writing this library. As I wrote, I realised it was actually very useful and present it here now in the hopes that the wider network engineering community will find it useful and also contribute back MIBs.

An example may best illustrate the library:

First, we need to instantiate an SNMP object with a hostname / IP address and a community string:

$ciscosw = new \OSS\SNMP( $ip, $community ); 

Assuming the above is a standard Cisco switch, let’s say we want to get an associate array of VLAN names indexed by the VLAN ids:

print_r( $ciscosw->useCisco_VTP()->vlanNames() ); 

This yields something like the following:

Array (
    [1] => default
    [2] => mgmt
    [100] => cust-widgets
    [1002] => fddi-default
    ...
)

It really is that easy.

See the GitHub project page: https://github.com/opensolutions/OSS_SNMP

Top 15 UI Libraries on GitHub (with 1500+ watchers)

I was just reviewing an accessibility presentation where the author had an interesting slide on the top 15 UI libraries on GitHub with 1500+ watchers. Here they are with links and descriptions (my own comments in italics):

  1. Bootstrap, from Twitter - Simple and flexible HTML, CSS, and Javascript for popular user interface components and interactions. A favourite of mine and I’ve used it on Open Solutions, ViMbAdmin, TallyStick, ePayroll and more.
  2. impress.js – It’s a presentation framework based on the power of CSS3 transforms and transitions in modern browsers and inspired by the idea behind prezi.com. (GitHub page).
  3. chosen - Chosen is a library for making long, unwieldy select boxes more friendly. Another plugin we love and use in a number of projects.
  4. jQuery-File-Upload - File Upload widget with multiple file selection, drag&drop support, progress bars and preview images for jQuery.
  5. jquery-ui – jQuery UI provides abstractions for low-level interaction and animation, advanced effects and high-level, themeable widgets, built on top of the jQuery JavaScript Library, that you can use to build highly interactive web applications. (GitHub page). Another favourite of ours and we use it along side Bootstrap with the jquery-ui Bootstrap theme.
  6. spin.js - An animated CSS3 loading spinner with VML fallback for IE.
  7. deck.js – Modern HTML presentations (GitHub page).
  8. Skeleton - A Beautiful Boilerplate for Responsive, Mobile-Friendly Development.
  9. Foundation - An easy to use, powerful, and flexible framework for building prototypes and production code on any kind of device.
  10. showoff - the best damn presentation software a developer could ever love (example).
  11. ajax-upload - A file upload script with progress-bar, drag-and-drop (GitHub page).
  12. isotope - An exquisite jQuery plugin for magical layouts.
  13. Timeline JS - Beautifully crafted timelines that are easy, and intuitive to use. This actually looks really cool and very pretty.
  14. etherpad-lite - An Etherpad based on node.js – Our goal is to make collaborative editing the standard on the web.
  15. ColorBox - A lightweight customizable lightbox plugin for jQuery.

 

As an honourable mention, if you use Bootstrap and it’s modal dialog, take a look at Bootbox which provides wrappers for JavaScript alert(), confirm() and other flexible dialogs.

Some thinks that jump out at me from the above is that frameworks are very popular and, similarly, prestation frameworks are also very popular. There must be a deep hatred of PowerPoint and Keynote among web developers! The other take away for me is how a very small project – such as chosen – can become hugely hugely popular.

ViMbAdmin 2.1 Released – POP3/IMAP Access Restrictions

We’ve just pushed a new release of ViMbAdmin – version 2.1. The main highlights are:

  • it’s now possible to restrict access to a mailbox via either IMAP, POP3 or both. See this page on the wiki for more information.
  • it’s our first release requiring a database migration. But it’s really really easy – see this page for those instructions.

As always, a live demo is available at: http://www.opensolutions.ie/vimbadmin/.

ViMbAdmin – Migrating to github

I have recently been converted from and SVN user to a Git user. You can read about my road to Damascus moment over in my personal blog.

As such I have converted my co-workers and we have migrated ViMbAdmin to GitHub. We feel that the project is in an early enough stage to not cause too much annoyance with the current user base. We do sincerely apologise for all and any inconvenience caused.

Do you want to continue with your SVN installation?

Feel free to svn switch your base from Google Code to the following which tracks our master (i.e. stable / production / release) branch:

http://svn.github.com/opensolutions/ViMbAdmin.git

Migrating to Git

Just follow the instructions at:

https://github.com/opensolutions/ViMbAdmin/wiki/Install-using-git

and skip the database setup. Just copy over your application/configs/application.ini file to the new Git clone.

Using Official Packaged Releases?

No problem – you’ll now find new versions at:

https://github.com/opensolutions/ViMbAdmin/archives/master

 

So I’ve Made the Switch from SVN to Git…

…and I’m bloody delighted. 

The straw finally came when Nick forced my hand for a project we wanted to release through our work in INEX. I was pushing for Google Code but he had his heart set on GitHub. Now, in fairness, GitHub has some SVN bindings but after some research, I decided to dive right in.

Now, there’s both a steep learning curve but also a complete change of mindset required from centralised source code management (SCM) with SVN to the distributed model of Git. In the end, most projects will decide on a canonical Git repository anyway which pushes you slightly back towards centralised but there’s still a world of a difference.

So, what’s so good about Git? Well, lots. But first and foremost is it’s exceptionally powerful yet simple branching and merging that just works. And works fast – remember, with Git everything is local.

One work flow that used to kill me in SVN was that you’d be implementing feature X but someone needed bug Y fixed immediately involving some of the same code. Getting just the fix for Y in was tough and complicated. And branching in SVN isn’t quick or simple. In Git, I branch from the main development branch for every new feature, bug fix, etc and then merge what I need between them and back into develop when they’re ready to be pushed back to the agreed canonical repository.

I’ve been so impressed with Git that I’ve moved an open source project we created in Open Solutions over to Github: ViMbAdmin. I’ve also forced the rest of my team in Open Solutions over to Git and migrated a number of customer projects already. And we’re reaping productivity rewards!

How we work Git for projects was taken from this excellent post which I would fully recommend: A successful Git branching model.

Useful Git Links: