Team Development at Cost Zero

[PAGETITLE=Team Development at Cost Zero][Top Ad] Collaborative development has become ingrained in the minds and practices of software developers everywhere, to the point it's no longer a buzzword. A large part of the software being developed today has been completely or partially done by programmers over a network across long distances. Three things have greatly contributed to this: the Internet ubiquity and the advancements in bandwidth offerings, the rapid development of specialized tools and services for programmers wanting to share work across long distances, and the increasing complexity of the software required by users. It's unquestionable that the great motivator and contributor to this software development paradigm has been the open source community. Most of the advancements in tooling and development practices concerning collaborative development has come from that group. This activity stems from the fact that open source development is almost exclusively done by large groups of developers across the globe. The Apache project includes developers from five continents, all contributing source code from their homes or work places. However, collaborative development has also become an integrated part of closed source development. Not to the same scale, for sure. But it's been a practice among hobbyist and small developers in pursuit of creating free and commercial products. Likewise, companies large and small have been collaborating on all types of projects, either through contractual partnerships or through subcontracting. Interestingly enough, the current landscape of collaborative software tools and services presents a problem to small teams of developers wishing to collaborate over closed source projects. A good portion of the collaboration services available on the Internet are free. These primarily include revision control and bug-tracking tools. However, these websites do not generally allow the hosting of closed source projects – when they do, it involves paying a monthly fee. These groups of programmers are often ad-hoc partnerships between individuals, with very little monetary resources, no investors to speak of and no company formed, wishing only to create a product before they commit to the legal and fiscal unpleasantness of creating a company and a brand name. Essentially, individuals with no money to speak of, but still wishing to give it a try like everyone else. What this article presents is a complete solution for collaborative development of small team projects at no cost, past what is already there with the Internet access bill. Initial Considerations. Explaining every step of the procedure is unnecessary and outside the scope of this article. The aim is to expose the available options. It's assumed that the reader knows what revision control, bug-tracking or Apache is and how they need to be set up (or at least know how to learn from the many online manuals and tutorials). There is however, a comments section to this article linked at the end, and I will be more than happy to answer any questions there. The core of the whole setup is the local installation of revision control, bug-tracking and database management services that will serve the team through the Internet. An ad-hoc website will also be installed and a communications solution presented. Most of this will be server software. ADSL Internet connections aren't ideal for this type of setup, considering the great limitations they usually impose on the upload link. Ideally, one will want a DSL, cable or fiber connection, and any team member having such a connection should be considered as the prime candidate for installation. With small teams (2 or 3, maybe 5 programmers at most) it can work reasonably well if installed over ADSL. In any case, it is recommend that the team share responsibilities instead of everything being installed on a single member machine. One member is responsible for hosting and maintaining the revision control service, another bug-tracking, another the database, et cetera. [PAGEBREAK][PAGETITLE=Revision Control][Top Ad] It's impossible to overstate the importance of revision control in modern software development. Maintaining full history of the project's various stages of development is perhaps the most important breakthrough in development practices ever devised. Even lone programmers use revision control for their projects and it has long ago moved past the software development industry and into other areas of production. File hosting services are meant to share and synchronize files between different computers across the Internet. The services act as storage gateways allowing anyone to connect to them and without any other intervention, synchronize the contents of their shared folders in real-time. The transparency level at which the service works is remarkable and makes it ideal for this purpose. SkyDrive, Google Drive or Dropbox are possible solutions. These are free file storage services with enough reputation to guarantee some piece of mind against data theft. But read on. Whether you use a centralized revision control system like Subversion, or a distributed system like Git, you will most likely want to have a central repository. That will be the one you want to share. The idea is to create the repository in a convenient location on the hard drive and then set up your file hosting service of choice to share the repository top folder among the other team members and their computers. Team development at this scale is rarely about shared responsibilities. Usually, every member will be assigned their own area of the project and normally won't commit against someone else's files. Branching and merging is a rare occurrence, left only for carefully designed steps of the development process. As such, centralized revision control seems a natural choice. On the other hand, distributed revision control is still some sort of black art among developers not accustomed to open source development. It is possible that among your team, some developers aren't knowledgeable about this type of revision control and haven't yet gone through the paradigm shift. My advice is to make the decision in a two-stage process. The team should first default to a centralized revision control system. The two most important considerations; if everyone in the team is knowledgeable about distributed revision control, or if the development strategy for the project will include a good deal of branching and merging. If any of these are true, then a distributed revision control solution is what you should choose. The file hosting service will also require some careful thinking. Of the three services suggested here, Google Drive has been the one coming under the most fire from users and experts alike, due to the seemingly vague nature of the company's terms of service, as well as the fact that Google allows itself to retain user files even after they have deleted from the respective accounts. However, SkyDrive and Dropbox aren't much behind, being often criticized for similar or whole new reasons. SkyDrive specifically imposes severe restrictions on the type of content it allows to be hosted, with some users having already seen their accounts shut down due to "inappropriate content". This suggests Microsoft actively monitors and inspects a user's files on SkyDrive. At first glance, Dropbox seems to be the service of choice, and that's my personal suggestion. There's very little in Dropbox's terms of service that differ from Google Drive. But the major two differences are important: Files deleted will stay deleted and it won't use anyone's files for anything else other than what is expected as part of the service. Above all, it should be clear that we get what we paid for - these services are free. Under a no cost obligation, relying on a 3rd party's free file hosting service will invariably put a burden on any privacy and copyright concerns. To be sure, there's a couple of other solutions that don't involve the use of a third-party service. The repository can be installed on a local machine and made available through SSH. One will of course need an SSH server for this. There are various flavors of FTP too, something like FileZilla server can support FTPS, which is SSL-based. For Windows, freeSSHD is a good option that can serve both SSH and SFTP. Alternatively, since an Apache is likely to be installed, one can set up Apache and WebDAV to serve the repository. This last option is a complex one to setup however, and it will vary between revision control systems. It should only be considered by someone with good knowledge of both Apache and WebDAV. [PAGEBREAK][PAGETITLE=Bug-tracking & Communications][Top Ad] Bug-tracking comes a close second in the list of most important achievements to software development technology. It provides the means for project development organization and filtering. It's an essential aspect to team development since it greatly reduces communication noise between team members by committing all of the software development stages and requests to a centralized database. Bug tracking operates as a software development-oriented issue tracking system. Modern implementations are developed as three-tier client-server applications and include project management features. The presentation tier makes exclusive use of the Web browser. So, in order to implement the team bug-tracking system we need to combine a database server and a Web server. This is best achieved by making use of any of the available solution stacks on the Internet. AMP (Apache, MySQL and PHP) is a well-known general-purpose solution stack that comes on the three major OSs, LAMP for Linux, WAMP for Windows, and MAMP for Mac. We are going one step beyond. Bitnami offers zero-configuration, software-specific stacks. Among them you get a choice of three well-known bug-tracking systems. Trac, Redmine and Mantis are powerful solutions that will answer most...

Team Development at Cost Zero

Page 157 –