27 Mar 2012

0 Comments

Changing our Git Workflow

by Tom H.

We’ve been using Git for quite a while now. We don’t have a single SVN repository. This makes for happy developers!

For a while we’ve been using Git Flow as our preferred workflow. It’s been pretty good, certainly from the point of having some sort of a recognised workflow/process. The only problem is, it’s turned out to be a bit heavyweight for what we want.

We love agile development, and for us, this means:

Short sprints of development
Regular releases (minimising serious issues)
Flexibility to experiment and throw away bad ideas
Team spirit and collaboration

The problem with git flow is it’s far better suited to a fairly fixed release cycle. We’ve found the release mechanism is cumbersome for quick/regular releases, and… it’s all a bit heavyweight for the entire team. We want all of our team to feel they can commit and contribute without feeling they might break something in the process. We also want to encourage communication, collaboration and experimentation!

So, the solution is, we’ve switched to Github Flow way of working. So what is it? The basic principles are this (stolen from http://scottchacon.com/2011/08/31/github-flow.html):

Anything in the master branch is deployable
To work on something new, create a descriptively named branch off of master (ie: new-oauth2-scopes)
Commit to that branch locally and regularly push your work to the same named branch on the server
When you need feedback or help, or you think the branch is ready for merging, open a pull request
After someone else has reviewed and signed off on the feature, you can merge it into master
Once it is merged and pushed to ‘master’, you can and should deploy immediately

Here’s an excellent presentation that explains it:

What about clients reviewing code before it might be production ready? Well, we simply push a given feature branch to our stage server. If two developers are working on a separate feature branch, they can either merge each other’s feature branches or create a new shared branch for the purpose of a client reviewing code.

We’ve dropped all our develop branches and the team have been merrily discussing pull requests and getting stuff done. So far so good, we are liking the shift a lot.

8 Dec 2011

2 Comments

Bugs are not spoons

by Mark P.

After thoroughly washing up this morning I still managed to find a spoon at the bottom of the bowl once I’d drained the water away. There’s always at least one bloody tea spoon left. Always.

This last spoon also appears in development… When we’ve “finished” a sprint or even a whole project. It’s time to go spoon hunting. Those little bastard spoons hiding in the Fairy Liquid. Sometimes they’re obvious sometimes it takes some digging or looking at things differently than you would normally.

These spoons aren’t bugs, they’re the little things that make a big difference, whether UI, UX, feature tweaking, removing or adding. The hovers on a button “feel wrong”, “this image isn’t pixel perfect”, etc.

We’ve adopted the spoon metaphor and come to love it. We create spoon lists on a regular basis now. I think it originated from @iamkeir and since then we’ve fully embraced it as term for the final 10-20% of a project.

3 Sep 2010

3 Comments

We use FreeAgent (review)

by Sarah H.

The most important thing for a small business – or indeed any business – is to be able to track regularly and accurately the state of the cash flow. This means knowing how much work has been invoiced, controlling credit, closely monitoring costs and managing client accounts.

However, if it’s the most important thing, it is probably also the routine task that can get overlooked, forgotten or that gives way to more urgent daily issues.

When I joined Simpleweb as office manager a few months ago, I was introduced to Freeagent, the accounting software designed to help small businesses do all this.

Great, I thought. All good stuff that is going to make life easier. Providing the information goes in methodically and accurately, the current situation can be monitored daily.

So, what do we like most about Freeagent?

Well it’ s free! (well almost. There is a small monthly license fee of about £22).

The dashboard on our home page gives a great point of quick reference. It is graphic and clear and shows at a glance the state of the bank account, how much has been invoiced out, payments received and a debtors list so I can see immediately who needs to be chased for overdue invoices. It also shows a tax timeline with key payment dates for PAYE/NI, VAT and Corporation Tax and a quick reference profit and loss summary.

The contacts database means you can keep all your contacts up to date and the work flow section allows you to project manage work for key clients, generating estimates, time sheets and invoices. We use the invoicing function as it links into the payment details and bank reconciliation – but for project management we prefer Basecamp

To manage the cashflow, providing you upload your latest bank statement regularly to Freeagent, you can easily reconcile and account for money in and money out. The information you put in here is categorised into cost centres and feeds into the accounting section and profit and loss making costs monitoring and end of year accounting much easier.

The My Money section can be used for PAYE & NI, generating payslips, keeping records of expenses and more.

What do we not like so much?

Well, three months on, you can imagine my disappointment with one very important, you could say vital, aspect of Freeagent that has turned out to be seriously lacking: the PAYE and National Insurance calculator.

By their own admission, Freeagent say on their website: “. . . this is a simple payslip calculator” and that “if your payroll needs are more complex than the simple calculator supports, you can always use another payroll calculator and edit Freeagent to match”

We were nearly caught out by this simplicity and had been putting blind faith in the payroll figures generated by Freeagent. However, it turned out that there were some discrepancies in the NI payments, albeit small differences. Luckily we realised quite quickly that the system was not really robust enough to cope with the nuances of our payroll and the complexities of UK tax and NI deductions so we have handed the payroll function to our accountant who runs it all through Sage. Peace of mind. I do not think we will be duplicating effort by replicating the data in Freeagent. The net salaries and tax paid will still be accounted for in Freeagent, but not the calculations or payslips which will come from Sage.

Like any system, Freeagent is only as good as the data that is put into it and we have made a judgement call about which parts are really useful to us and then to make absolutely sure that we keep those sections routinely and accurately up to date – then it really does make life easier!

25 Mar 2010

2 Comments

11 things we do for effective bug tracking

by Mark P.

Dealing with bugs can be a very dangerous experience… For a small company it’s possible to drown in the bloody things. Effectively getting a process in place can be difficult and time consuming. We currently have a few big projects on, so we know this first hand.

The Basics

A few “givens” are necessary before any kind of bug process can be implemented.

We need to have:

A “deployment” server (the live one)
A “stage” server
A system for tracking bugs

While developing a sprint there should be a “development” server – bugs are never reported on a development server as it’s always “bleeding edge” work in progress. This development can still be discussed in whatever project management software you may be using.

We use Mantis for tracking bugs, it’s not got the best interface around but it’s depth suits us well at the moment.

Our process isn’t some multi page document it’s just a simple list of rules that will make the client’s and our lives easier during the bug tracking phase.

All bugs and features must go into bug track

One mans bug is another mans butterfly… Put everything into the bug tracking system, ambiguous or not. Leaving things out just causes confusion later.

Any communication around a bug or feature must be in bug track

There’s no point getting a zillion emails about an already reported bug. As a project manager if you have to put it in; do it. Any correspondence can then be centralised around that bug.

All communication with developers must be through bug track

When a developer gets emails directly it messes with their minds. Nine out of ten developers rise to the challenge of the client, which is great, but the project manager needs to be involved, hence keeping everything in bug track.

When a bug has been received it will be assigned to a developer

In your bug tracking software you should be able to assign bugs to developers. This shows the client that you’ve acknowledged the problem. Once a problem is acknowledged and a line of communication is open a certain amount of stress is relieved on both sides.

If the bug is deemed to be a “feature” it will be assigned to the project manager for discussion

Developers are lovely. They will fit in this small feature even though it’s not really a bug. Anything ambiguous needs to be assigned to the project manager.

When we have looked at the bug we may have some questions

The developer will change the status to “feedback” – asking for what we need to know. The quicker it’s answered the sooner the bug will be resolved.

When we’ve fixed the bug we will push it to the “stage” server for approval

The staging area is the latest stable release before the deployment to the production server.

If the client is not satisfied that the bug is fixed – why?

We need clear information stating why and under what circumstances. This needs to be attached as a note against the bug in bug track.

When the client is happy that the bug is fixed – close it

A note in bug track needs to be attached to the bug. Only then will we “close” the bug.

We will not deploy to the live server individual bug fixes unless they are catastrophic

Deploying individual bug fixes is inefficient, so unless they are really really bad, they will be stored up into a daily or weekly release.

We will provide a list of fixed bugs deployed to the live server

It’s important to know what has been promoted from the staging server. A clear list of bugs and their issue numbers should be provided to the client either by email or in your project management software.

This is a work in progress, an evolutionary process if you like. It would be fantastic to compare this with other agencies so that we can collectively improve the way that we treat clients and out own efficiency.

The Blog - Archive for process