Project Organization

From GPWiki
Jump to: navigation, search
40px-sprout.png   This article is a stub. You can help out by expanding it.


When working on a large piece of software it is important to have a clear, preferably automated, way of dealing with the files. This is especially true when more than one person is working on the project.


Automated build process

Using an automated build process has several advantages:

  • It makes compiling a lot easier for third parties, other developers and even yourself
  • It speeds up compile time by only recompiling the objects that need recompiling, saving countless hours on larger projects

Most IDEs provide a good way to do this. Usually all that needs to be done is to create a new project within the IDE and then make the project. The IDE will automatically determine which files need recompiling.

There also exist other programs for automating the build process. They include:

Backups

Backing up your data is a valuable process(so valuable you will be upset if you do not). It might seem like a useless, time taking process unless you have ever had the bad luck of losing lots of data yourself. The following article explains various methods for performing backup operations on Windows systems. Don't forget the quote: "It's not 'if' a hard drive will crash, the question is 'when'". Your hard drive can crash at any given time, while you're taking a shower, while you're a sleep, while you're at work, or even when you're playing the game Monopoly! Backing up your sources and project files is always a good idea, especially when you're gone for long periods of time. There is various ways of doing it, and I highly suggest you get rid of Vista and convert back to XP, for Vista still has many glitches and bugs, for example, with an HP that runs on XP, every week it will give you a reminder to back your files up on multiple CD disks, you can even set the reminder for the next day, so when it asks you to back up your files, go ahead and do it, because it's a warning of advice, of course you will need a few CD's if you're a space waster like me, but your "Hard Work" is worth more than money, so take the warning as a serious piece of advice!

Collaboration/Communication

In addition to a version control system, the following tools can be highly useful for team project development.

  • Google Docs - Allows multiple people to collaborate on documents.
  • RealVNC - Remote control; allows a user to work on a remote computer as if sitting before it.
  • PuTTY Free Telnet and SSH client
  • Trillian - Free IM client that supports all major IM networks (AOL, ICQ, MSN, Yahoo, IRC).
  • Pidgin - Much like Trillian, but open source. Formally known as Gaim.
  • OpenSSH - Open-source implementation of the SSH protocol. Allows remote terminal-connections.
  • Gobby - Open-source collaborative text editor. Saves sessions, files, and has syntax highlighting.
  • Meebo - Browser Based IM Client, supports a number of IM networks. Create meebo password protected rooms for team chats, supports chat logs.

Wiki software can be a very valuable tool for game development teams. Members can update pages very easily plus attach files to each page. You can post documentation, brainstorming outlines, class outlines, flowcharts, and other useful documents. Here are some popular wiki scripts:

Project Hosting

There are several online sites where you can host your project.

Version control

Version control systems allow you to keep a history of each change made to your software. You can easily revert to any of the previous revisions of your software, allowing large changes to be undone if they leave a big mess in the code or break the application. The version control system also has a central repository where the program and its revisions are kept. This can be backed up to ensure you don't lose any work.

Version control systems are especially useful for projects with more than one developer. It allows all changes to be kept in a central repository and for new changes to be easily updated in each of the developers copies. The other developers can see what files have changed and where. Version control systems also provide means for dealing with conflicts for when two developers are working on the same file.

Some popular version control systems include:

There are also decentralized version control systems, which do not require a central repository. This allows for more flexible workflows.

  • Bazaar, like Git but portable and easier to use
  • Git, used by the Linux kernel developers
  • Mercurial, very similar to bazaar in some aspects, recently relatively widely used in the open source community

Continuous integration

Once you have automated builds and version control setup you're ready for the next step: continuous integration. Continuous integration is the practice of automatically rebuilding your code (the "integration" part) every time there is a change made to the code repository (the "continuous" part). This is especially helpful when working on projects with more than one developer, since each developer's changes to the code base are immediately integrated into the rest of the source and the results can be built and tested right then. Contrast this to what happens when two developers working on a single piece of code both commit some code that breaks something into the source repository, even though each developer may be able to build their own copy of the source on their own machines. Now the code in the source repository is invalid, and who knows how long it will be before it is noticed.

Continuous integration doesn't mean just building the source and checking it for errors. It can also mean building documentation from the source, running unit tests, doing a test deployment, etc.

There are several free software tools to help set up continuous integration.