Most of the software development process should be automated, namely test running, deploys, all that jazz. But in the fast-paced small startup arena, most people just don’t know or don’t care about this enough to take the time, or don’t have that time. Even worse, critical areas, such as communication and planning, are overlooked and not even included in that cycle. So here’s my proposal:

Implement a simple, continuous deployment process that takes care of your software needs (testing, releasing) as well as your project planning needs (measuring, reflecting the state of the project), and last but not least, your communication needs (who needs to know what and when).

To do this, you will need a few things:

• A Source Code Management tool –a coder-candy wonderland, where your dev team will be happy, and GitHub is the perfect service for it.
• A Team Communication tool – where everyone is and can be reached at any time, and Flowdock is amazing for that.
• A Project Planning tool – and Trello Boards works just great.
• A Continuous Integration tool – a place identical to your production environment where your project will be tested, like Jenkins, Travis-CI, or your own little set of scripts.

That you will wire up in a particular manner:

• Make sure all and every test is run before any code reaches a deployment server.
• Make sure the deployment server fails eagerly and loudly. The more verbose, the better.
• Make sure people get the information they need. Not everyone needs to know it all to function efficiently.

Hoping that we get it working, a week or so in after launch, you start to see more and more random errors occurring randomly, and there’s a load of new cards on Trello, and sometimes developers don’t update their cards, and Flowdock rooms get filled with unnecessary details of commits and pushes that don’t matter outside the development team. Chaos. Well, not really, but going further into that direction. Let’s see how we can fix this.

Flashcards

To properly reflect the state of your project, and whether you are using SCRUM or Kanban, or just managing cards in a board, you will have a set of lists. We will use 4:

• Icebox, or the less urgent stuff
• Backlog, holding the stuff the team will be working on next
• Working, what everyone is doing right now
• Deployed, tasks that are considered to be finished.

If cards are tagged by feature names, it’s easy to keep track of the state of the project. For instance, if you are building a cashflow tool, some of your top level features would be: Budgets, or Reports. This is incredibly useful after you grasp which colors are what feature set, which ends up being pretty obvious:

A pattern for notifications

Communication is foundational. But that doesn’t mean that everyone should know everything regarding the development process.

• A commit gets pushed.
• A branch gets merged.
• A test fails, and why it failed, and who broke it.
• A deployment begins, and who triggered, and when.
• A deployment ends, and who triggered, and when.
• A deployment fails, and why it failed, and who triggered it, and when.
• An error occurred on the production or staging server, and a full trace of the error.
• A new server spawned.
• A server was killed.
• KERNEL PANIC, or any other issues that will arise.

While your mileage may vary, the rest of the people in the company might just need to know the following:

• The staging server is under maintenance.
• The staging server is up.
• The staging server is down.
• A new feature has been deployed.

This way, you keep your team updated on the stuff that matters to them. If at one point you separate your development from your DevOps team, then most likely an infrastructure error involving a virtual machine not being able to spawn is not of interest to the development team in the same way a failing test for a ui component is of no interest to the DevOps team.

A Continuous Deployment Process

Continuous Deployment is by no means something new. Everyone knows about it or at least heard the term once or twice before. In a nutshell:

• the dev team pushes
• the cd server tests
• the cd server deploys

And that happens

Caveats and Implementation

Of course, this story is less a cautionary tale and maybe more a recommendation. This is what I consider to be an unobtrusive development process that helps the organization as a whole, specially when multidisciplinary teams are formed.

1. Github commits can move Trello cards.
2. Github commits and pushes show only in the Flowdock rooms that matter.
3. Trello card updates only show in Flowdock to the users involved.
4. The CD server informs people over Flowdock when things happen.
5. The CD server can move Trello cards.

In the next post I will implement this unobtrusive process using the aforementioned services and AWS

Summary

These are my thoughts on this matter. They are not final, as I’m constantly looking for flaws and improvements, so feel free to reach out on twitter and let me know what you think would improve this draft. Hopefully this got you thinking about your development process as well.