Agile Web Operations

Photo by brettanicus

Given proper steering, teams must be empowered to decide and execute decisions on their own. This means that a team must have the proper make-up including designers and architects, application and database developers. Once a team commits to the story backlog, they must work together to ensure that all stories are delivered by the end of the sprint. If you've recently migrated from a department structured organization, making the whole team understand that they succeed or fail all together will take time.

Photo by Randy Son Of Robert

From the dawn of time, humans have always worked together as a team to overcome hardship and danger, and make the community stronger. Specialization naturally grouped people together to form hunting parties or food gatherers and later on governing councils and religious groups. This grouping together of dedicated, like-minded people forms the core of our success as a society today.

Fast forward to modern times. It's no coincidence that popular sports teams typically number between five and twelve people. Could you imagine a football team with 25 players per side? The communication and coordination of such a large group would be much to inefficient for such fast paced game play. To fans in the stadium, their reactions would seem slow and imprecise and probably not very entertaining. Yet this is precisely how many companies have organized themselves in the last century.

Have you ever found yourself in Sprint 4 or 5 without a single release under your belt? Is it because the new functionality involves a big database upgrade or depends upon coordinating three or four different departments? Not only does this kill motivation, but it's extremely risky to push out this mountain of code and configuration changes to production all in one release.

Developers are people too. Believe it or not, they have needs and wants just like everyone else. Here are some, which the Operations department should be able to satisfy for a more harmonious and productive workplace.

Robust development environment

Just as sysadmins have those black sheep servers in the back of the server room used for testing the latest and greatest version of sysinstall, developers need a dedicated sandbox where they can try out all their great ideas. Give them some elbow room in their development environment (at least 4 GB of RAM), plenty of disk space (500 GB) and a quad-core workstation. What in the world would they need this much power for on their desktop? Virtual machines, heap dump trace analysis, and virtual machines. Did I mention virtual machines? These give developers the means to run their own test environments directly on their local system saving both you and QA a lot of time and hassle. Imagine simply giving the disk image you used to install the production instance configured with cfengine to the developer to run! Now any configuration change you make in the master test environment can be broadcast right to the developer's machine.

Building on my previous article "The Branch Not Taken", I'd like to convince you of the importance of code ownership. In Garret Hardin's essay "Tragedy of the Commons", he describes the burden that communal freedoms place upon a finite resource.

Protecting your release branch

If you consider stable, production ready code as a finite resource, it naturally follows that granting everyone write access will slowly, but surely, degrade its worth. So, in the interest of keeping your release branch in a pristine state, you're going to have to remove write access to the release branch (or trunk) from your developers. Pretend you're putting up a fence around your codebase. But it's not just any fence, I'm talking about a six-foot high, chain-link fence with a locked gate.

Whether you're running your website from the trunk or a release branch, you've already taken the first important step - you're using a source code repository. Depending upon the size of your team and website, the way you manage this repository will vary tremendously. I'd like to share some of my experiences in managing code repositories - a must-have skill set for agile web development.

Development branches vs. stable, protected release branches

Creating development branches has certainly become mainstream nowadays and there are plenty of articles out there which explain merging techniques. While I've heard a lot about stable, protected release branches like the Mozilla Foundation uses for Firefox, others often type cast the trunk into a "sand-box" role, open for any quick and dirty commits. For this reason, the trunk is commonly accepted as "bleeding-edge" - to be checked out and deployed at your own risk.