Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked
both on light independent projects and in the environment of large global enterprises.
As Flowdock enters public beta (opens on March 10th!) we’ve begun doing continuous deployment. As an agile software development shop, we also test extensively and practice continuous integration. At the same time we need to monitor that Flowdock is running smoothly and when problems occur, we can fix them right away. All this requires fast working channels of communication so in the center of it as the hub of our team, is naturally Flowdock. I’ll walk you through our development process from the developer’s point of view.
Committing changes
We use git for version control. Each time someone pushes commits to a branch, an email is sent to Flowdock with tagged information on
commits that were pushed (committer, commit message…)
component and branch, into which was pushed
This lets us do real-time code reviews. We habitually discuss individual commits inside Flowdock. We use a git post-receive hook to pipe the changes into Flowdock via email. The hook is available here as a gist on GitHub.
Continuous integration
Whenever someone pushes some changes into the master branch, our continuous integration server runs all the unit tests in the project and if they do not pass, an alerting email, such as the one above, is sent to our flow. The message comes with details on who to blame so others can target the correct amount of mocking towards the culprit.
Continuous Deployment
When the tests pass, the master branch is then deployed to our QA environment.
All deployments send properly tagged messages to our flow in Flowdock. I can always tell what was deployed:
component: front end, back end, specific service…
environment: production, qa…
changes: log of commits the deployment brings into the environment
The QA deployment runs acceptance tests, which make sure all the important use cases function properly in a production-like environment. For acceptance tests, we use a combination of Cucumber, Selenium and RSpec. Once everything passes in QA, the deployed version is tagged a suitable candidate for production deployment. Next we do some smoke testing in QA, and finally deploy to production.
Flowdock also gives me a deployment log. For example to see front end deployments in production, I just search #deploy #production #frontend in Flowser.
Exception notifications
Whenever something goes wrong in production, we get notifications to our flow. This way we can debug problems together, immediately when they occur.
To show you a bit about our processes, we have been recording our daily scrum stand-ups and now compiled it all to a single time-lapsed video.
As you can see in the video, in start of each sprint we have our stories, represented as white A5s and tasks as Post-its on the left side of the whiteboard. Stories are prioritized from top to down, top being the most important.
When a task—for example, “make a time-lapse video”—is put on the board, it’s moved from left to right according to the approximate amount of work done, measured in Zörgöns™. On the most right is the “done” column, where tasks regarded as complete are moved.
Video holds about 4,5 sprints (10 weeks) of daily Scrums in 30 seconds. Check it out below.
Here is some proof to back up our overly lengthy tagline, Rails-doc is the first Rails documentation app that wasn’t developed by one guy in his underpants. Rails-doc.org has an actual team behind it – a team that employs an agile development process.
There’s hardly a better visualization of Scrum than a timelapse video! It shows the progress of our second sprint.
I think everyone who participates in Scrum ought to know the essential laws that Scrum was created to deal with. But much more important, I think that the client must acknowledge them, since I do not believe it is possible to be successful at buying software without being fully aware of these fundamental laws, coping with which is of utmost importance when it comes to developing software. It never hurts to remind oneself of the laws, that Scrum was created to deal with:
Specifications and requirements will never be fully understood (Ziv’s law)
Where your mind sees a square, the next guy’s sees a circle. Specifications should be documented but the maker of the specifications has to be fully available for the development team to ask questions and to communicate eye-to-eye. The maker of the specifications, who should be or at least strive to be the best expert of the actual requirements, absolutely cannot be a stranger to the development team.
The users will never know what they want until the system is in production and maybe not even then (Humphrey’s law)
The users may also believe they need something they in actuality have no use for. Users customarily claim they need a feature for a business requirement that can often be covered much better by a very different feature. Users cannot make specifications. Users’ feature requests obviously still need to be heard so the developers can come up with the right feature to cover the business requirement and empower the user to reach his goal. Users’ goals and the software’s business requirements should be crystal clear to the developers and the developers need to show interest towards them.
An interactive system can never be fully specified nor can it ever be fully tested (Wegner’s lemma)
Important to acknowledge, and just as important it is to understand that regardless of the impossibility, full test coverage, automated and manual, should be attempted to achieve. The specification of a software is always a work-in-progress, even after the software itself is ‘completed’. This needs to be accepted and specification documents need to be constantly edited during the process of developing the software.
