This is something I've had in mind for quite some time but I can't find the right method to do it.

So basically, I'm working with 6 different websites, all running Magento CE 1.9.2+

On those websites, I am using a bunch of extensions that me and the team I'm working with have developped (here we're talking 50+ extensions) and the code for those extensions is stored on Bitbucket. So I ain't the only person managing those extensions, we're 3 people working on them.

At the moment, when I want to add a feature/fix a bug for one of those extensions, here's my workflow:

  • Install the last version of the extension on one of the website via Modman
  • Fix the bug/add a feature/test
  • Manually copy the changes to a local folder that contains all my extensions
  • Commit and push via GIT from this extension folder to Bitbucket (1 Bitbucket repo per module)
  • Then the new version of the module can be installed via Modman

Important note: I'm using modman with hardcopy here, no symlink.

My biggest problem has been highlighted in bold: I want to be able to skip this step because it's a big cause of problems (some files are forgotten sometimes, wrong copy/paste, involves human action).

So, how can I improve my workflow in order to get rid of this manual copy/paste step ? I'm open to suggestions here.

I very often take the following approach which is pretty framework agnostic.

  1. Check out the module you want to edit to /path/to/my/module
  2. Create a branch for your piece of work (branched off of the relevant tag etc).
  3. Commit work to this branch (don't push).
  4. In your project, define a local repository to your local copy of the module. This is so that your project can pull in unpushed changes from your LFS.

    {
        "repositories": [
        {
            "type": "path",
            "url": "/path/to/my/module"
        }
    ],
    
  5. You can then composer require your specific development branch (so long say your projects minimum-stability allows it).

    composer require namespace/module dev-branch-name-here
    
  6. You commit in /path/to/my/module, composer update namespace/module in the project, see it install and test.

  7. When you're complete squash your commits and push up.

I find this approach works well for M1 modules using https://github.com/Cotya/magento-composer-installer, as the symlinked install can be a pain sometimes and trip you up when adding new directories or paths which were previously not symlinked by modman.

Links that may interest

Debugging

  1. Use composer require namespace/module dev-branch-name-here -vvv to see the branches you can use locally.

  2. Double check that minimum-stability has been set to dev in the project you're installing the module into.

  3. Your requirements could not be resolved to an installable set

Found by reading Patrick Schwisow's comment here.

If other packages have requirements on the package you are changing, your development branch may fail to meet those requirements (which will result in "Your requirements could not be resolved to an installable set of packages."). To fix this, you can do an inline alias to that all other packages will see it as a specific version.

In short you can update your composer.json to force it to a specific version while developing, make it read like:

"namespace/module": "dev-branch-name-here as 1.2.3"
  • Another interesting approach here. Thanks for your input – Raphael at Digital Pianism Feb 13 '17 at 9:09
  • 1
    This is a good one. I tend to use path type repos for project modules that I wont re-use and then git or packagist for modules I will re-use. – David Manners Feb 13 '17 at 9:10
  • 1
    @DavidManners I use this flow above in combination with satis. Modules are permanently in satis, but I don't want to push anything up into the mainline until I've tested and run locally. So it's use the above workflow, and then push and tag and wait for satis to pick it up. – Luke Rodgers Feb 16 '17 at 18:48
  • @LukeRodgers, with this workflow you don't use modman at all and all your module files are placed inside magento files? (you don't have .modman folder for your extensions). Did i understand it right? – MployBy May 23 at 10:50
  • Hey @MployBy, I don't use modman directly. However, I'm not sure if Cotya/magento-composer-installer uses it under the hood, it's been a while since i set up a new magento1 module. – Luke Rodgers May 23 at 10:54

I'm using modman with hardcopy here, no symlink.

There's your problem. If you cannot change this setup for your shop deployments, consider working on shared extensions on a separate instance where you use modman with symlinks.

I use composer with the AOE composer installer to clone the extension repositories directly into .modman but installing modules from Git with modman works too I suppose. Either way you can work directly in the module Git repository.

  • Yeah as I said in the comments, the reason is one of the dev uses Windows and IIRC we had some issues with him using symlinks – Raphael at Digital Pianism Feb 13 '17 at 8:42
  • 6
    Oh, I did not see that. Give that dev a VM :) – Fabian Schmengler Feb 13 '17 at 8:56

So my idea here for you is to start working with composer even for Magento1. If you had your own packagist, which is not too hard to manage now that aws and google cloud is in place, or you can use public packagist. You would have "easy" access to newer versions in your Magento1 shops.

This means that when a newer version comes out you can composer update and it will automated the copy process for you.

Have a look at https://github.com/Cotya/magento-composer-installer for Magento1 via composer.

With this approach you can also directly work on the git repository under the vendor folder if you have it set to copy in the .git and so can push changed back to their repos without having a separate checkout. Though note you have to be careful here and make sure you know what branch you are on otherwise you can remove your code (done that a few times).

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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