You got that great idea for an application that will be a huge success. High level feature set and design is done and you are ready to start bashing the code. Before you do, you might go through a checklist of tasks that should be done before the coding starts.

There are three things that I consider as prerequisites of every project (apart from knowing what the high level scope of the project is).

• Some kind of a project management tool or a task tracker
• Version Control System (VCS)
• Continuous Integration (CI) framework with jobs for each phase from the build to deployment

I, for one, am often inclined to simply start bashing the code. However, that temptation should be avoided in favor of a better and more stable project development.

Project management tool

There is no shortage of tools for project management. Three of my favorites are JIRA Agile (formerly called Greenhopper), Trello and plain old sticky notes. Each of them are oriented towards the different audience and types of projects.

JIRA is a beast with endless possibilities. It allows creation of workflows, reporting, issue tracking… It has both Scrum and Kanban capabilities including estimations, backlog management, sprint planning… It can handle projects of all sizes. I love it. If I’d need to choose only 3 tools, JIRA would be one of them (together with Jenkins and IntelliJ IDEA). It allows me to have total control over the project and, at the same time, freedom to tailor it to suit almost any project management need the team has. For management of enterprise projects or a middle to big size open source project, JIRA is the tool.

JIRA has certain difficulties. Its learning curve is a bit steeper than with tools like Trello. You will need to learn how to work with the tool. Assuming that JIRA is used with its full potential, it might take anything from 1 week to a month until it is fully up and running. However, once you get there it’s a really rewarding experience. JIRA is a beast with a lot to offer if team is ready to invest in the initial setup and the administration overhead. I would recommend it for projects with large number of developers, testers, designers, customers, managers…

Trello is on the other side of the spectrum. It is intuitive, easy to use, no fuss, list driven, Kanban type of board (without “work in progress” function). It is a fantastic piece of software that can easily be adapted to serve almost any type of activity that requires general purpose task tracker. One big advantage of Trello is its price. It is FREE. I would recommend it for projects with less than 10 users and limited budget.

White board or a wall with sticky notes is the third option. If you are lucky to be a member of a team where everyone is on the same location and nobody works from home, notes are a great way to go. Having all tasks visible all the time and being able to do the physical action of moving a note from one lane to another provides greater collaboration and team bonding than any software solution.

I use both JIRA and Trello on a daily basis. JIRA fills my office hours (and is sponsored by the company I work for) while Trello fulfills my needs for personal open source projects (with or without collaborators).

No matter the choice, project or task management should be the first thing to set up at the very beginning. Ideas and requests will come and they will be converted into tasks (stories, acceptance tests…). Without a way to write them down and pass them through some workflow, things can easily be forgotten and left undone.

The rest of the article will use Trello as the tool of choice.

Trello project

I tend to keep things simple and organize my Trello tasks into only 4 lists (first 3 of them come by default): To Do, Doing, Done, Demoed/Reviewed. To Do contains tasks that someone thought off but the work on them did not start. Before somebody starts working on a task, it should be moved to the Doing list. When the task is done, it is moved to the list with the same name. By done, I mean done done. Code is written and tested and there is nothing else left to do; the feature is almost ready to be delivered. The only thing pending is demo and/or review. All team members and stakeholders need to be aware of that feature or task. Once it is deployed, the task can be archived.

This is in stark contrast with the way corporate world is managing projects with their endless workflows, types of tasks, reviews and confirmations. Corporations are often trying to compensate their distrust of people working for them with ever-increasing project workflows and verifications. I find simplicity rewarding so I’ll just pretend that big and inefficient corporations do not exist.

Here are my initial tasks in the To Do list:

• Setup Repository
• Setup CI Server
• Setup builds in CI
• Setup unit tests in CI
• Setup deployment in CI
• Setup BDD scenarios in CI
• Organize kick-off
• Define first set of features

Version Control System (VCS)

Hopefully you are already used to have your code in some code repository.

All your code should be located in a repository that is capable of maintaining commit history, marge different branches… Developers code on their computers or servers and once they’re done code is committed to the repository. That commit should trigger CI workflow (explained in the next section) that will perform build, testing, deployment, etc.

Some of the commonly used are Subversion, Git, Mercurial and Perforce. Git and Mercurial are distributed source control heavily used in open source projects. Subversion shines with its simplicity. Perforce is popular within bigger companies and is the only one among those four that is not free. All of them are supported by major IDEs.

If your company is still using one of the “dinosaurs” like CVS, change it to something else or quit your job. Life is too short.

If you’re not going to host your own source control repository, first step is to choose a hosted service. The list of available service providers is big with following being some of the most popular:

• GitHub: Supports Git and SVN.
• SourceForge: Supports CVS, SVN, Git, Mercurial and Bazaar.
• Google Code: Supports SVN, Git and Mercurial.
• BitBucket: Supports Git and Mercurial.

Detailed comparison of open-source software hosting facilities is available on Wikipedia.

Almost all repositories allow free hosting for Open Source projects.

Continuous Integration (CI)

Continuous Integration originated as one of the 12 original practices of Extreme Programming (XP) and is probably the most important and beneficial software development practice. Once any code change is committed, CI tool should get the code, build it, perform all sorts of tests, generate different metrics (code coverage, code complexity, etc) and deploy it to one or more environments.

Some of the more popular tools are Jenkins, Hudson, Bamboo and Travis.

My recommendation would be to use Jenkins or Travis.

Jenkins is very flexible. It supports almost any language and build step one can imagine. Most of its functionalities come from the plugin system. Library of plugins is huge and it would be hard get to the situation that some need is not covered by at least one of them. Downside is that time is required to learn how it works and what are the best practices. There is a recurring case that one organization or project ends up with hundreds or thousands of jobs that are hard to maintain due to poor practices. Another downside is its resources consumption. Big number of build jobs and plugins can drastically decrease its performance.

Travis is a hosted CI solution. Unlike Jenkins that relies heavily on its Web interface for most of the tasks, Travis is based on .yaml files that resides in the project code repository. It is tightly coupled with GIT. Travis is easy to start using and free for open source projects. One can have the CI process set in Travis in a matter of minutes. This ease of use comes at the expense of flexibility. If your project is “special”, you might need more effort to make it work with Travis than with Jenkins.

I use both Jenkins and Travis on a daily basis. Jenkins is used for big projects often done in a “non-standard” way while Travis fulfills my needs for personal open source projects. In cases when both tools fulfill my needs, I tend to choose Travis due to its simplicity.

No matter the tool choice, CI is something that every software project should do. Benefits are too big to be ignored.

Basic CI workflow is often similar to the following set of jobs:

• Checkout the code from the repository
• Compile the code
• Execute unit tests
• Create distribution
• Deploy the distribution to a test environment
• Execute functional and integration tests

If any of the jobs fail workflow is stopped and the team is notified about the problem. If everything is “green” the application is ready to be deployed to the live system. Since code commit is the last manual action (excluding posible usability testing) unit tests need to be written in advance with Test-Driven Development (TDD). Same applies to functional and integration tests. They also need to be done in advance with some form of Acceptance Test-Driven Development (ATDD) or Behavior-Driven Development (BDD).

CI is a big subject and will be explored in more depth in one of the next articles. As always, Wikipedia is a good start.