13

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.

LazyOne
  • 158,824
  • 45
  • 388
  • 391
Milanzor
  • 1,920
  • 14
  • 22
  • 1
    My a quick glance, Git might be able to handle your use case. Have you read anything about it yet? – Tim Biegeleisen May 02 '17 at 09:47
  • 1
    what about git-branching? – zachi May 02 '17 at 09:52
  • @TimBiegeleisen Not sure what you're aiming for. I have read about Git and work with it daily. I'm by no means an expert but I don't see how Git can provide a solution to all of the problems we have (for example database changes). – Milanzor May 02 '17 at 09:53
  • I guess zachi is talking about using git as a real distributed source control tool. @Milanzorg when you say "We use Git as source control and have 1 branch we all work in" you mean that you set up a working tree somewhere on a box and developers connect and work all at the same time at that working tree and then you commit every so often? If that is so then "you are doing it wrong!" (even through it's possible, as you are a witness to). _Under normal conditions_, each one of the developers should use their own resource and work separately committing on their local and then merge stuff. – eftshift0 May 04 '17 at 13:54
  • If you are all working at the same time on the same resource you are just not taking advantage of version control, or at least you are not using it to the fullest. – eftshift0 May 04 '17 at 13:57

6 Answers6

4

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).

Martin van Driel
  • 1,397
  • 2
  • 12
  • 20
  • Yeah, that is definitely the way forward, but we're afraid if the conflict hell that would come with it. – Milanzor May 02 '17 at 13:03
  • @Milanzorg You mean in terms of version control conflicts? A migration file for each database change is a way to avoid such conflicts. I'm trying to understand what you mean. Happy to help you further! – Martin van Driel May 05 '17 at 11:37
2

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.

Mike Tung
  • 4,735
  • 1
  • 17
  • 24
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!
kpollock
  • 3,899
  • 9
  • 42
  • 61
0

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.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • I'm well aware of us 'abusing' Git this way, each having our own working copy, committing to own/shared branches and merging them towards production/staging branches is what we want, but before we can set this up, I want to tackle a few obstacles first. For example, how will the changes developer A does to a MySQL database table be inflicted upon the the MySQL database of developer B? The code changes developer A makes can be committed, but what about the database changes? I can hear you say migrations, that is an option, but because our work overlaps all the time (1/2) – Milanzor May 04 '17 at 14:18
  • (2/2) we don't wanna be pulling changes every half hour and having to fix all the possible occurring conflicts and then having to execute migrations with possible conflicts. I'm not trying to sound negative, just trying to find solutions to problems I foresee with the suggested idea's. Thanks for the answer btw! – Milanzor May 04 '17 at 14:19
  • Database changes will be a pain, no matter what. On a project I used to work for we used a defined file where we would write the sql statements that were needed for tickets. When merging them we would _always_ get conflicts, but that's fine because given that they are SQL stuff it's mandatory to test them against a DB to make sure that they integrate well. Once you merge enough tickets, you could end up with a big sql file. – eftshift0 May 04 '17 at 15:06
  • So, when we released, we would clean up the file on the following commit so that if people were to start working from that version, the file would be empty again (changes would already be part of the DB for that release so the changes would not be necessary anymore). Hope that helps a little bit. – eftshift0 May 04 '17 at 15:06
0

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.

artspb
  • 1,127
  • 1
  • 10
  • 19
0

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.

Kristijonas
  • 151
  • 1
  • 10
  • I read a lot that Docker could be a very special kind of unstable hell (https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/ for real life experiences). Any sort of VM would do the job of letting the devs all have a std environment, I imagine. – kpollock May 11 '17 at 09:17