2

I am currently working on a team of four people trying to develop a simple news website. We are having a hard time figuring out the best way to collaboration. I've found other threads that suggested using Features module; however, that is outside of our scope at the moment. Can you suggest a simpler way to collaborate?

closed as too broad by kiamlaluno Dec 26 '15 at 18:01

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • OP clearly mentioned that he knows about features module and this not a dup!. – Bala Mar 31 '14 at 9:07
  • Can you give a bit more information on your working environment? For example are you in the same timezone? Is it possible for all your developers to have access to the same database? Are you using any sort of version control system for your code yet? Are you all working on the same code, or are some working on design, some on themeing, some on backend etc? – rooby Apr 1 '14 at 10:18
1

Since you specifically mention the Features module in your question, (also mentioned in the upvoted and accepted answer to: How do I manage collaborative development on a Drupal site?) I shall assume you're asking about how to share the database and code under development among team members, and not about tools for team collaboration ("groupware") in general.

First, let me say that I don't think Features is the right tool for this task, and shall propose an alternative set of tools.

A prerequisite for team collaboration is to have a staging server for testing out development versions of the project that is separate from your production server. All development code is tested at the staging server, and only pushed to production server when it is stable and ready for deployment. However, the developers doesn't work directly at the staging server. Each developer work at his or her own workstation, using a revision control and source code management (SCM) to coordinate his or her work with the rest of the team.

The SCM system allow team members to work in parallel on different branches of the code without interfering with each other. Only the master branch is deployed on the staging server for testing purposes.

To mirror the database between production, staging and workstations, there is a module named Backup and migrate that can be used if you're on shared hosting and not managing your own database. If you're managing your own database server, this is the only project on that server, and you use mysql, the following pair of commands are handy:

To dump:

mysqldump --all-databases --opt -u root -p > DUMP.sql

To restore:

mysql -u root -p < DUMP.sql

If yours is not the only database on that server, script some version of mysqldump (or equivalent if you're not using mysql) that dumps your databases only.

Make a policy that it is the database on the production server that is master. The staging server and workstations should be a copy of the production database, not vice versa.

Note that Drupal 7 keeps all its admin setting in the database. This means that mirroring the database between the production site, staging site and workstations will migrate admim settings without Features.

Now, for sharing the code:

The standard way for sharing code among the members of a development team is to use SCM system. Drupal happens to be default be managed with such a system named git.

Git allows the use of local or remote repositories. If the team members are located in the same physical space, you can set up a local repository on your staging server. If they're spread geographically, you can set up a remote repositiory. If you don't mind others having read access at your code under development, you can use a sandbox at Drupal.org as a remote repository. You can also use a project area on GitHub. GitHub is not only a repository, but comes with a some tools for collaboration, and allows both public and private repositories.

Basically, a SCM system allow team members to pull source code and documentation from the respository shared by the team members, and push it back in again after having worked on it. The SCM keeps track of changes and if there is a conflict (i.e. somebody tries to push code that doesn't the contain the changes another team member has committed), it will tell you and also suggest a way to resolve this conflict.

Usually, with some cordial communication about how the tasks are divided among the members of the team, there will be no conflicts. But with the SCM system keeping track of things, conflicts become manageable even if mistakes are made or communication fails.

There exists a lot of tutorials on getting started with and using git (GIYF). Two I will recommend are: the git-scm website and Pro Git by Scott Chacon.

Not the answer you're looking for? Browse other questions tagged or ask your own question.