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!

Answer 2

You should store your GIT repositories in centralized location, e.g. in Github, or in one of your local servers. Any developer could pull/push the changes from/to central repository and work with local copy (no SMB networks).

Consider using Docker containers. This would allow to have you all exactly the same development environments.

Database changes could be done using database migrations. See this library doctrine/migrations.

Answer 3

While I personally would prefer using Git and its branches, the deployment feature of PhpStorm could be a solution for you. So instead of using a network bound share, you can have a local copy which will be updated from the external resource. Here are the configuration tutorial and the tutorial on how to keep it up to date automatically.

Answer 4

After having added a comment to the original response, I think this has to be provided as an answer:

• Use git properly as a version control tool. By having all developers work on a single resource you are definitely not taking advantage of what version control is all about. Have each developer work on their own working trees (locally or on a server if you want to keep it that way) so they can take advantage of git's features for local development (create their own branches, fast operations, not messing up with what other people are doing) and then merge stuff together in upper development branches when things are ready. This should take care of quite a lot of your problems.

That's top priority on my list.

Answer 5

One solution I can think of could be to use a version control system like git. Sounds to me like you want to all be working on the same project and possibly same feature at the same time.

To minimize your merge conflicts I suggest making a dev branch and for each feature it should branch off the dev branch and be isolated until there is either an update (someone merged or you are done with the feature and merged). The other developers can then pull those changes in from dev and continue on their feature.

If the problem is based on environment you can use the docker feature in JetBrains ides to create a common environment to work in.

Answer 6

A good improvement would definitely be working on your own local copy of the application. As you describe this would fix the performance issues, but will give you issues concerning database updates.

A way to manage database updates is to make use of migration files for every database schema change. Say you make a change, you add this change to a new migration file which you add to the git repository. Having those files, everyone is able to apply all migrations on top of their local development database to keep their database up to date. It also makes testing very easy because you can just reset your database at any time and apply the migrations again.

You might have a look how others apply this. There are back-end frameworks who support this out of the box (for example Laravel for PHP).