Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git client.

Take care of your tasks!

Thursday, December 20, 2012 Luix 0 Comments

As probably most of you already know, we at Codice Software use the Branch per Task development pattern. This has a lot of advantages for us; one of those is deciding what to integrate and where. This gives us a very flexible way to build new releases; it's like building customized releases, à la carte.

What I want to explain now is what a task means for us. The picture below depicts the task life-cycle:



So, at the beginning of every Sprint we decide the Sprint Backlog, and assign tasks to the team. Then, when a developer starts working on a task he / she opens it. When the task is done the developer change the status to Resolved, and our internal testing system picks the task, run all our automatic tests suite and if anything fails the task is reopened.

In the meantime, a different assigned developer reviews the task. Again, if he / she finds some kind of code smell or a potential bug he / she reopens the task.

When the task is reviewed then other developer validates the task, testing manually the issue. If a bug related to the changed code is found he / she reopens the task. Otherwise, the task is verified and ready to be integrated in the mainline.

As you can see this is a complex cycle, we care our tasks a lot, they are like children for us. We see them born, grow, educate them when a teacher (reviewer, validator) tells us that it is misbehaving at school, teach them how real life is when tests fail and then they go to the university (integration), where they meet other tasks and become a task useful for the society (the product).

This information is logged in our internal task control system, like the medical history or the resumé of a person.

Then, if later on any problem related to that task is detected (via annotate or method history in most cases) and a developer asks us how we educated it, we explain to that developer what we did.

So, in the end, our concern as developers is about educating tasks to help other developers to do their work :-). Isn't that beautiful?

Luix

0 comentarios:

Subscribe to: Post Comments (Atom)