Skip to main content
Clarified that we use Client_Module extensions.
Source Link
Matthias Zeis
  • 7.7k
  • 3
  • 32
  • 50

We are using Magento setup scripts located in the sql and data directories to propagate data changes to all working copies and environments. This includes configuration settings, creation of new tables, attributes and so on.

More often than not, this changes are[Update] projectProject-specific code and can't be attributedgoes into several Client_Module extensions.

Nonetheless often enough we need to aadd data migrations (reusablei.e. setup scripts) which can't be attributed to an existing extension. Thus we use a Company_Client module (or Client_General, someting like that) for these changes.

Imagine multiple developers working on the same project at the same time. It may happen that developer A and developer B are both bumping the version number of Company_Client and create a new upgrade script. Even if you update your working copy frequently, you will get conflicts more often than you like, have to change the version of your local Company_Client extension and make sure that the scripts of your fellow colleagues run when you fetch their changes.

Three solutions from the top of my head:

  1. Create many extensions for project-specific parts (pollutes the code pools with many unnecessary extensions).
  2. Create one extension per developer for upgrade scripts (may work, but doesn't make sense).
  3. Bite the bullet and manually do that kind of conflict resultion I explained before.

How do you handle this?

We are using Magento setup scripts located in the sql and data directories to propagate data changes to all working copies and environments. This includes configuration settings, creation of new tables, attributes and so on.

More often than not, this changes are project-specific and can't be attributed to a (reusable) extension. Thus we use a Company_Client module for these changes.

Imagine multiple developers working on the same project at the same time. It may happen that developer A and developer B are both bumping the version number of Company_Client and create a new upgrade script. Even if you update your working copy frequently, you will get conflicts more often than you like, have to change the version of your local Company_Client extension and make sure that the scripts of your fellow colleagues run when you fetch their changes.

Three solutions from the top of my head:

  1. Create many extensions for project-specific parts (pollutes the code pools with many unnecessary extensions).
  2. Create one extension per developer for upgrade scripts (may work, but doesn't make sense).
  3. Bite the bullet and manually do that kind of conflict resultion I explained before.

How do you handle this?

We are using Magento setup scripts located in the sql and data directories to propagate data changes to all working copies and environments. This includes configuration settings, creation of new tables, attributes and so on.

[Update] Project-specific code goes into several Client_Module extensions.

Nonetheless often enough we need to add data migrations (i.e. setup scripts) which can't be attributed to an existing extension. Thus we use a Company_Client module (or Client_General, someting like that) for these changes.

Imagine multiple developers working on the same project at the same time. It may happen that developer A and developer B are both bumping the version number of Company_Client and create a new upgrade script. Even if you update your working copy frequently, you will get conflicts more often than you like, have to change the version of your local Company_Client extension and make sure that the scripts of your fellow colleagues run when you fetch their changes.

Three solutions from the top of my head:

  1. Create many extensions for project-specific parts (pollutes the code pools with many unnecessary extensions).
  2. Create one extension per developer for upgrade scripts (may work, but doesn't make sense).
  3. Bite the bullet and manually do that kind of conflict resultion I explained before.

How do you handle this?

Tweeted twitter.com/#!/StackMagento/status/314689644010815489
Source Link
Matthias Zeis
  • 7.7k
  • 3
  • 32
  • 50

Avoid conflicts in setup scripts with multiple developers

We are using Magento setup scripts located in the sql and data directories to propagate data changes to all working copies and environments. This includes configuration settings, creation of new tables, attributes and so on.

More often than not, this changes are project-specific and can't be attributed to a (reusable) extension. Thus we use a Company_Client module for these changes.

Imagine multiple developers working on the same project at the same time. It may happen that developer A and developer B are both bumping the version number of Company_Client and create a new upgrade script. Even if you update your working copy frequently, you will get conflicts more often than you like, have to change the version of your local Company_Client extension and make sure that the scripts of your fellow colleagues run when you fetch their changes.

Three solutions from the top of my head:

  1. Create many extensions for project-specific parts (pollutes the code pools with many unnecessary extensions).
  2. Create one extension per developer for upgrade scripts (may work, but doesn't make sense).
  3. Bite the bullet and manually do that kind of conflict resultion I explained before.

How do you handle this?