EllisLab today announces changes to our internal development processes, including dropping Subversion in favor of Mercurial and adopting Assembla as our agile software development management tool. Along with these changes, CodeIgniter 2.0 pre-release code is in development, and is now hosted at the Mercurial-focused social coding site BitBucket.
At EllisLab we make ExpressionEngine, the CMS for web professionals, and CodeIgniter, the only PHP framework to receive praise from Rasmus Lerdorf, the creator of PHP. We’re based out of Bend, Oregon, but only two staff members live there. The rest are scattered roughly from West to East in Portland, Missouri, Illinois, Toronto, North Carolina, Ireland, the UK, Germany, and Austria. In addition to very little face to face interaction with one another, our developers have to deal with as much as a 9 hour difference from other team members. So we’ve adopted and continue to adopt methodologies and technologies to bridge those gaps and enable us to be as productive as if we were all in the same building, working the same hours.
Version Control
One no-brainer, and I hope most of you are using it as well, is version control. Since 2005, we’ve been using Subversion, and it has performed admirably, particularly during the majority of ExpressionEngine’s life when there were only two Sith developers working on a project. The first year that Subversion was in use, we even shared a single user and did not use commit messages. That works fine when you can read the rest of your team’s minds, and you aren’t using version control for revisioning, but merely for convenient file sharing.
But Subversion comes with a lot of baggage, some of which becomes heavier in proportion to the distance between team members, and as both your projects and team increase in size. Commits and diffs become laborious on even the fastest of networks. The size of the repository balloons if you try to use basic features of branches and tagging. Renaming and moving files is a pain, and can jam up your fellows’ repositories. And don’t even think about working independently and merging.
These and other issues led us to examine dozens of version control systems (VCSes) to find the right fit for our team. We looked at Git first, whose growth can be largely attributed to the popularity of GitHub, then Bazaar, darcs, Monotone, Perforce, BitKeeper, and so on. But after weeks of research and test use, we settled comfortably into Mercurial.
Now before the Git readers get their pitchforks ready and head for the comments, let me be clear that we are not at odds. Both are great distributed version control systems (DVCSes), have nearly identical features, and have a common enemy: Subversion. So our switch to Mercurial means that Git users win too - joining a growing army against centralized version control. It just happens to be that a few of the divergent features swing slightly towards Mercurial for our specific needs, but above all, our team enjoyed using Mercurial more than Git. Not that we didn’t enjoy Git, we just enjoyed Mercurial more, and why is hard to quantify but there was obviously no reason to fight it. We’re here to write code and create great applications; the more that our use of any VCS can fade into the background to accomplish that goal, the better.
Scrum
When your development team grows beyond two people, the mind meld dissolves, the ability to know at any given moment what the rest of the team is doing, and how well they are doing it dissipates. Cowboy coding’s ability to be effective diminishes. So a little over a year ago, we began looking at various agile software development methods, and decided to try out Scrum. It’s been a tremendous success.
To bring Scrum to a team spread across the world, we’ve been using technology to create a virtual office. Google Docs for shared spreadsheets to track our Sprints and burndown charts. Planning Poker to help us plan Sprints. Neither tool ever felt like a perfect match for us, though. Whether it’s the clumsy manner in which product backlog items are stored and moved to a new spreadsheet to create Sprints, or not having the hour estimation card that we really wanted to play - resulting in a lot of “I estimated 16 hours but I really mean 12” - these tools were getting us by, but were not the most effective.
Enter Assembla, a tool we came across in our search for a new VCS. Assembla is the perfect blend of what our developers and our product owners need for project management, and that mix is remarkably difficult to find. It gives developers the ability to use any VCS they like, including those on your own servers, fully integrated with a ticketing system that is built from the ground up for agile software development. Product owners are given a visual ticket organizer to effortlessly create Sprints from categorized backlogs. Add to that a Scrum tool to make standing meetings less intrusive to the varied working hours of our distributed team, and it’s near perfection.
Assembla is the product that is saving us from having to write our own agile software management tool. We’ve moved all of our software projects into Assembla. This is a tool anyone working in a team should check out.
This is a behind the scenes change of course so it may seem inconsequential, but all of our users will benefit. Like Mercurial, this logistical portion of our virtual office can just do what it’s meant to do and thus fade into the background, letting us focus on getting things done instead of on processes.
CodeIgniter
Of our communities, CodeIgniter benefits the most directly from these changes. The adoption of a new VCS and new internal development tools allows us to not only be more effective in CodeIgniter’s development, but also enables us to give you more and to interact more directly with you.
Starting today, CodeIgniter 2.0 is baking, and I’m thrilled to announce that with Subversion gone, in-development code is available publicly on its new home: BitBucket.
After adopting Mercurial, joining BitBucket was a perfect fit for our open source projects. It has a beautiful source code browser and will make watching code changes a breeze with its graphical changeset viewer and RSS/Atom feeds.
It also comes with a rich social layer, quick access to tagged versions, along with forking and patch queue management for advanced users. Do you find yourself making the same modifications to CodeIgniter before beginning a project? BitBucket and Mercurial can help you do that and share it with others with ease, using any version in the upstream repository.
We’re really excited to watch CodeIgniter’s growth accelerate due to these changes. A discussion of CodeIgniter 2.0’s features and direction will be forthcoming, so be looking for that in the future in the news section of CodeIgniter.com. What are you waiting for? Go sign up at BitBucket and become a zealot, following the CodeIgniter project!
Discuss this story
