Development environment with multiple developers on a single application

Question

I'm looking for a good way to optimise/improve the way my colleagues and I work on our applications.

We currently all work in PhpStorm on a MacBook Pro (2016), an Ubuntu server in our network and a working copy mapped on a SMB share to our machines (we sometimes edit the same files, making this inconvenient). We use Git as source control and have 1 branch we all work in.

We are noticing performance problems using PhpStorm over the network share, our application is quite large and having PhpStorm index everything makes it freeze and feel non-responsive all the time.

We're looking for a way to improve the way we work, streamlining the development of our application and removing the performance problems we have with the network share/working copy combination.

We are thinking of each having a working copy locally on our machines, having a virtualised webserver (Vagrant) and all running the application separately from each other. This would fix the issues with the network, however it would bring other problems, if I, for example, make database changes, these changes would also have to be done on my colleague's working copy.

Also, we make changes in the same files all the time, the last thing we want is fixing file conflicts every time we make change, nevertheless having to pull every commit another developer makes during the day, plus having to do their database changes manually.

TL;DR, what is a good way to work on 1 application with 3 developers.

Answer 1

https://www.atlassian.com/git/tutorials/comparing-workflows

Pay attention to the part where it says: "Developers start by cloning the central repository. In their own local copies of the project, they edit files and commit changes as they would with SVN; however, these new commits are stored locally—they’re completely isolated from the central repository. This lets developers defer synchronizing upstream until they’re at a convenient break point."

Once you get this idea, then the rest follows, I think.

1. Always update your local branch from master and test before checking in
2. Check in often! Multiple times a day. See point 1. Every checkin should contain both the relevant code and SQL script code (and any other resources), and should compile and work!
3. Merge conflicts will happen. There is NO magic wand, or strategy. In general, try to co-ordinate so that devs are generally working on isolated areas (this presupposes your code is structured nicely to do so. Which is generally a good idea, but too huge a topic for here). I advise keeping changes to a file with any code that is auto-generated to one developer at a time only. (this is experience!).
4. All database changes should be a script and hence a code file, handled just in the same way as all the other code in terms of version control, devs should test on their own local copy of the database before committing. You probably need someone to oversee the scripts before release, to look for conflicts. You can have a rule that there is one script file per database object (table, view, sp), makes it easier!