Working together in larger Teams

[thmsnhl]

Hi everybody,

we started our first Processwire driven project in my new company and for the first time, I was working on one site with more than 2 colleagues on the same site.

It didn't take long for us to stumble across some problems when multiple developers work at the same time, conflicts with updating the database on vagrant machines, like duplicate entries for page IDs, errors when setting up fields and stuff like this. We ended up working on a dedicated database server, that we linked to our vagrant machines and most of the problems were gone, but the performance of this constellation is really bad compared to our first approach with database running on vagrant machines.

I already tried to find a solution in the forums but I couldn't find anyone with problems like this.

So I was wondering: how do you manage projects with multiple developers on vagrant machines in a git-based workflow?

[Mobiletrooper]

Hey thmsnhl, 

 

I'm using ProcessWire for a few projects at work as well as for my personal projects. Originally coming from Ruby On Rails I also encountered problems with our database synchronization when it comes to team development on a single project. Depending on the project we solved this using Field/Template Export/Import while also only working on certain parts of the page. Most projects are already finished in terms of template/field structure so there is no need to have an always up-to-date local database snapshot.

If the project is not finished in terms of template/field structure we usually sit together and draft a "this-solves-everything"-kind of template/field and synchronize this to our local databases once and then just code ahead.

 

Other frameworks solve this by using Migrations and although ProcessWire does not support Migrations in the core (as of now) you can use this module: https://modules.processwire.com/modules/migrations/ (Here are a few code samples and documentation: https://lostkobrakai.github.io/Migrations/).

This module does not directly add tables and columns to the database like RoR migrations do but instead allows you to do nearly everything you can do in the Admin UI using code. You can for example create templates, move fields around, install modules, setup users etc.

It can be a bit tedious at first to learn all the new APIs this module offers but the benefits, especially for large projects, speak for themselves. 

These migrations can be safely checked into your git repository and whenever one of your teammates encounters a problem with his out-to-date database he can simply run the migrations files. 

So instead of adding templates and fields on production you write them in code and deploy your changes to production, then you migrate either using the CLI utility or the admin backend. You can also integrate this into your build toolchain (like Amazon CodeStar). 

 

Check this code example I bet it feels quite familiar:

<?php

class Migration_2018_01_16_12_32 extends Migration {
    public static $description = "Add postalcode to a hotel";

    public function update() {
        $this->insertIntoTemplate('hotel', 'postalcode', 'title');

        $this->editInTemplateContext('home', 'postalcode', function($f){
            $f->label = "Hotel Postalcode";
            $f->columnWidth = 50;
        });
    }

    public function downgrade() {
        $t = $this->templates->get('hotel');
        $t->fieldgroup->remove('postalcode');
        $t->fieldgroup->save();
    }
}

This adds a `postalcode` field right after the title field to the hotel template. And it removes this field when you rollback your migration.

This is how we tackle this problem.

 

[thmsnhl]

Thank you Mobiletrooper, I haven't found this earlier but it looks like a solid approach!

I will give this a try in the future.