Presentation
Fortylines development environment is centered around a distributed version control system. At any time, each developer has physical access to the entire software stack of a project. That includes source code (of course), documentation website, bug reports, ... As a design philosophy, all bits of a project are replicated on each contributor's local machine. Contributors only need connect to the Internet to exchange code, documentation and ideas. Having each contributor decides when to exchange their work is a key component of keeping a team productive.
As many human activities, releasing a quality piece of software requires coordination and integration of the work of many contributors, testing under multiple environments, editing for consistency, etc. Something often better achieved through as many eyes as possible. This is why mass communication such as public speeches, books, TV broadcasts, etc. has always proved through the ages to be the most effective way to distribute and test ideas.
Innovative products are, in a lot of ways, debates of ideas and need to be organized as such. A distributed infrastructure is thus primordial for thoughts and development purposes whereas an accessible forum is the backbone to release and publication activities.
Development cycles
As a developper, before any development activities can start you need to correctly setup libraries, tools and other third-party prerequisites on your local system. In many cases, this is a manual frustrating process that relies on clues scattered through README files, wikis and e-mail lists.
In contrast, pulling, synchronizing and other updates of the local source tree from a remote server is usually straightforward.
Impatient to start now, you still have to sort out through build flavors (release, debug, etc.), optional features and other esotheric build parameters a project might provide. That means a few more environment variables and command-line options to configure before you are ready to roll.
Type make, relax, get coffee and read the news while the machine builds executables and related bits.
You are high on caffeine when the first run of a smoke test to validate the current work brings you back to reality. Computers never lie. They execute instructions faithfully. Your logic is flawed. Sober up and start to investigate what is actually going on.
OK, it is now time to edit something somewhere, writing, deleting and moving text around. You feel the power? You are just so smart, unbelievable! See previous step for the sobbering moment.
After some time in an edit/make/run cycle, somehow everything looks to work as expected. It is time to share those edits with the rest of the developper's community. You thus generate a patch (a set of edits that when applied to the source repository will reflect your changes).
Since changes might have unintended consequences, you test exhaustively before publishing your patch. A regression (a once passing test now failing) might appear. Different inputs might trigger bogus results. In any case, you are back for another round of edit/make/run cycles.
The patch looks good now. You, the author, or an independent reviewer/committer, can submit the patch to a branch on the shared remove server, effectively publishing the changes to the whole team.
Development is moving forward until your team decides the project is code complete and stable. Words such as freeze, alpha, beta or release candidate are thrown around as you package the project for delivery. This is an important step for everyone, the first time weeks, months, years of development will hit customers and other parties.
A few days before your product ends up in the wild. Now seems the appropriate time to check the package is sane. At the minimum the package should install correctly. Under-real-conditions tests and other items might also be on the checklist.
Congratulations, you shipped the product. People love it, some use it extensively. Specific and general feedback are welcome but need to be organized. A few things might be improved, ideas and features refined. After all, developpers live to implement changes.
Roles and activities
Release role
All components of a project are replicated on each contributor's local machine. As a result, at any time, any contributor's local machine can be elected to be the release (i.e golden reference) platform. Since any local machine is surely not configured to handle mass traffic that goes on with being a golden reference, there is, in practice, a dedicated machine that acts as release. The main emphasis in fortylines infrastructure is that release is truly a "role" definition. There is nothing, nowhere in the system, as far as implementation and tools are concerned that can distinguish a random local machine from a release machine. A release machine will see heavy traffic and the hardware needs to keep up with it. The machine can either be rented as a service, installed on a rented virtual server, or built on an in-house machine. Either way, setting it up follows the exact same procedure as setting up a contributor's local development machine.
The release machine is internet facing and subject to all kinds of related threads so best IT practices require to have a plan for access control and data integrity before any machine is booted. These areas are highly dependent on the software business you are building and no technology can provide turn-key solutions. Tools and policies beneficial for a project might not always be appropriate for another. None-the-less sensible and often used practices exist for network services.
Forum
Today, coordination of many contributors is primary done through mailing lists, a shared source repository and web-based services. Fortylines network services for mail and shared source repository are pretty conventional. The most interesting thing is that the servers live behind a firewall and no other machine is connected behind that firewall. As a design rule, there is no "local" network. All machines, either connected from a coffee shop or from the room next door, see the same firewall and connect to the servers by the same virtual private network settings.
The web-based services of a software organization usually includes static documents, an editable wiki, a bug tracking system, a source code browser and some ways to deliver nightly build results. All pieces are usually coming from different vendors with their own authentication systems and technical implementation details. Fortylines approach to information distribution is to integrate all editable bits (code, web pages, bug reports, etc.) into the same distributed control version repository and to provide tools such as semilla to publish the repository as online documents.