Based on the principles of ideas and architecture over coding, community based collaboration over individual and isolated effort, I have decided to redo my Project Flow & Tracker agile based project management tool based on the new Open Atrium “do-it-yourself project” kit. Not only do I get a huge kick in the butt for starters, but I can give back all the new functionality I develop as shareable features. Talk about win-win!
- What’s all the fuss about Open Atrium?
- It’s all about features!
- First steps towards Open Atrium based and feature shareable Project Flow & Tracker goodness
Open Atrium is described as “Part intranet, part do-it-yourself project…”. Heading over to the Open Atrium home page, I clicked on Features and watched the video. The video shows what you get out of the box (group-based sections, each with its own subset or complete set of features: Blog, Calendar, Group Dashboard, Documents arcive, Shoutbox (private twitter), Case Tracker (issue tracking system); each feature can be enabled in private (group scope) or public mode. Very impressive.
Then I read “The fun really starts when people start sharing the features they build for their own Open Atrium with everyone else. Then everyone doesn’t just have access to six features but also a bunch of others that are easy to plugin to the basic Open Atrium package.” And there are going to be feature servers, and it sure sounds like some good clean fun is happening.
But, what are features, apart from… obviously being features?
Drupal has always been a building block, toolset type of website application framework, and the Content Construction Kit (CCK) and Views modules have been allowing us to implement custom form-based persistible content types and listings of those content types for a long time now. One of the great things about these modules is that when you implement a content type or a view, you can export it into a text file that can be placed under version control and easily deployed by being imported into another Drupal website application.
It turns out that features wraps this same “export/import” goodness around a lot of other stuff, so you can work in terms of bringing together components (CCK fields, Views, configurations, custom code) into a nice manageable, deployable bundle called… a feature.
A component that has this characteristic is said to have “exportables”.
This whole system, forming the heart of Open Atrium, is built around a whole series of modules (features, context, spaces) and fits in with an exciting new set of packing and deployment tools (drush, etc.) being discussed at http://groups.drupal.org/packaging-deployment and forming part of the larger scoped http://groups.drupal.org/aegir-hosting-system.
It looks like the classic Drupal problem of how to deploy work done on a development site to a production site without disturbing its content (both being database based) may be on its way to being solved once and for all.
“These scripts will become obsolete when an improved system is implemented. There will be no silver bullet, however, many projects are being developed to help: Patterns, CoCKTaiL, Context, Spaces, Deploy. There is also a movement to implement import/export for all configuration options: Exportables, Features. Until all configuration options across all of Drupal and contrib are supported, these scripts will be here for you to help you migrate configuration settings.”
So looking over the Open Atrium documentation, with emphasis on the How to Build a Feature section (more on this below), I decided right then and there to go reverse engineer my Project Flow & Tracker on OpenAtrium! First of all it seems like a really fun and painless way of trekking through this cool package and deploy jungle. Secondly, I just don’t have time to build Project Flow & Tracker from scratch; and now I can contribute my own features (agile approach interface for projects; hierarchical multiple views on project, iterations, features (huh?), user stories, roles, tasks, issues; bidirectional traceability from requirements to iterations to user stories to tasks, on through to version control commits, etc) back to the community as I go!
And, needless to say, blogging about my progress every few days right here!
I downloaded the 6.3 MB tarball from the link ( http://openatrium.com/sites/openatrium.com/files/atrium_releases/atrium-1-0-beta1.tgz ) on the Open Atrium home page and untarred it as ./atrium-1-0-beta1 under a convenient project directory. I then carried out the following command to get a clean “atrium” directory I could then symbolically link to new untarred versions (and then hopefully update by exporting and importing features? looking forward to finding out):
$ ln -s atrium-1-0-beta1/ atrium
I then created a database and a virtual host and pointed my browser at the appropriate URL. As is the case with any regular Drupal install, the opening page asks you to select an installation profile, so I chose “Atrium by Development Seed” rather than default Drupal. I clicked on the Save and continue and button and the next screen asked me which language (out of English, Arabic and Spanish) to select. I chose English and clicked on the Select language button.
The rest of the install went as per any Drupal installation except that after filling in the database and basic site info, Atrium was installed, including a bunch of third-party modules. Then there was an Atrium installation complete page, saying that ./sites/default/files/pictures had been created and that the content permissions had been rebuilt. I was congratulated and sent along to my new site.
In the next article I will share with you my first explorations of this test Atrium site, and then the basics of the development environment I set up for rebuilding Project Flow & Tracker on top of this exciting framework.