3

Our company is new at Magento development so we are still figuring out a good dev cycle. I read the guide that Magento provided. But still not sure on how to develop with a team (5-10 people). Our goal is that we each have our own environment where we can code custom module(s) and we have our own (feature) branch in Git. My question is should we use a shared database or each have our own database? Here's is what I think about pro's and con's for each option:

Shared database

PRO'S

  • We have the same cms content / products and dummy data only needs to be added once

  • If we go live we don't have to figure out which one is the right one to copy or to export the configuration from.

CON'S

  • Someone installed a module and disabled it but other developers do not have the code yet.
  • The Base_url is different for some environments

Separate database

PRO'S

  • Make changes not worrying that other developers will have a problem

CON's

  • We need a way to merge the database's into one.

So are there other pro's con's that you? Know how are you working? Which method would you recommend?

| improve this question | |
  • Shared databases, especially with request heavy applications such as magento/2, can be extremely slow. Even more so if they're remote. Also worth noting that if something catastrophic happens to your shared database, unless you're vigilant about backups, you won't be able to recover from another team members database. – Lewis Oct 18 '18 at 13:34
1

  • You make the repo restricted from other developer to push directly on master .

  • Make the devs have the same database of live before starting the project.

  • Dev create branch from master , make whatever it is assigned for , create pull request , and after his code is merged into master , the other dev branch its behind and they need to sync their branch .

  • Example dev 1 install an extension with composer , when his branch is merged into master , and the dev 2 update is local with the extension already merged , he will got the same database as the Dev 1 (exept the configurations , but it doesnt matter since the configs usually are made on production site as customer want).

  • The only thing you need to concern is when having one developer task of upgrading the magento version and other dev is working on a large module regarding database modification . In that case you let know the devs about the steps of the workflow , so the dev that is doing the module have knowledge of the magento upgrade is being made.

  • Keep in mind to test after the merge first on the dev sites instead of production just to be sure.

| improve this answer | |
  • But if in this case dev 2 creates dummy products (or cms pages) dev 1 will not have these products. – Arno Vande Cappelle Oct 18 '18 at 9:09
  • Because no need to have those since they are "dummy configs" :) , the main configs are the live configs , and when they deploy ,they dont deploy the dummy configs . The configs are updated manually . – Ylgen Guxholli Oct 18 '18 at 9:12
  • But if we have other data that needs to go to production? For example we want to use the advanced content manager module (marketplace.magento.com/blackbird-contentmanager.html). Here you have content types that should be "exported" to the production environment. – Arno Vande Cappelle Oct 18 '18 at 9:19
  • Still , its not good using more than 1 developer working in one extension configuration , because will be a mess . Let one dev worked on those configs , and if he tests on his local , he passes the configs in qa envoriment (not in production directly) so you as a Tester or who can Review the work developer is doing , make the approve to go or not to go for the configs update in production . That feature isnt yet lanched yet by the extension . – Ylgen Guxholli Oct 18 '18 at 9:28
  • But as i said let one dev working with that. When i did the list i dint tell that the devs should not update the db ever. Yes they should but in intervals you looks like you need to have your devs having the latest database , for ex. when you finish deploying the configs of the content manager on production, you tell the dev to do a refresh of their local database. – Ylgen Guxholli Oct 18 '18 at 9:28
1

I think it's better to use a separated database when you have a big team to work in a single project. other developers will not affect of someone's change.

what you just need to do is when other developers want to make changes of the specific developer, just get his/her code into the local system.

just try to run below command it will automatically deploy all database change, code cache etc.

php bin/magento setup:upgrade && php -dmemory_limit=6G bin/magento setup:di:compile && php -dmemory_limit=6G bin/magento setup:static-content:deploy -f && php bin/magento indexer:reindex && php bin/magento cache:clean && php bin/magento cache:flush

my suggestion is to use github/bitbucket to get code instant of others.

| improve this answer | |
1

We have the same cms content / products and dummy data only needs to be added once

That's something that InstallData and UpgradeData are made for. Every block, cms page, stores, and other important system configuration should have an installer in code repository to make sure all enviorments' databases will get proper important data and configuration when setup:upgrade is run.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.