Tips or thoughts on my new development workflow

Magento 2 Setup
1

Been using M1 since 2011. I’m a little late on the research front with regard to migrating to M2.

I have yet to kick the tires in any significant way regarding M2. But right off the bat composer is very new to me. I like the idea of running a simple script to install and remove packages. I just wonder what the best way would be to keep myself organized.

Correct me if I’m wrong. But it seems that composer can install from cloud (repo.magento.com) or possibly a local path, is that right?

Currently for M1. I have a git repo on bitbucket with a development and master branch. And simply the development branch is on server a and master is on server b(production).

Basically all the code is just there. Whenever I needed to test changes I’d just manually delete an extension via ftp or ssh by deleting the files/folders. And then uploading the files/folder via ftp. If things didnt work out I would checkout to reset but if they did I would commit. And eventually pull on master.

I was thinking it might be a good idea to separate some things. Such as
Having one pristine folder that is whatever my installed version of magento is
One folder that has packages
One folder that has magento and packages

Is this too complicated? What are you doing in this regard?

That’s all I can think of for now. Will probably have more questions in the future.

Thanks!

2

Hi @Roboboit and welcome.

There’s a lot of people in the same boat as you, leaving it quite late to look at migrating. You’re in good company. Besides, you started using Magento about 3 years before me - So, you could probably teach me a thing or two :slight_smile:

Composer
I had never heard of Composer before 2017, when I first started looking into Magento 2. Now that I’ve wrapped my head around it, I would never go back. It looks more intimidating than it is. There’s a load of documentation that can be found online, but after a while you realise that you don’t need to know all that much in order to use it. Most of the time, you’ll just be copying/pasting commands from instructions.

Check this post I wrote a couple of days ago (Choosing a Magento 2.3 Installation Method that's right for you). You’ll see where I stand with regards to Magento distribution.

My Workflow
The way I work, is by using 2 or more Servers. The Addition servers are assigned to Developers for them to work on.

  • Managed Dedicated Server (Production)
  • Unmanaged Cloud Server #1 (Development)
  • Unmanaged Cloud Server #2 (Development)

Composer was used for the original installation of Magento on the Production and all subsequent core updates.

Creating the Original Development Servers was created using this method (How to migrate Magento 2 from one server to another). All additional Development Servers are then just mirrored from the Original Development Servers using a Snapshot (Cloud Host Tool).

And finally all Custom Code is done on the Development Servers and is tracked via a Git Repository. When I want to launch new Custom Code on the Production Server then I Pull the git changes directly onto the Production Server. No code is ever edited directly on the Production Server (or any files uploaded to it). Side-Note: We don’t really cover Git topics on the forum - There are much better sources like stackoverflow.com. I don’t even know how to use branches properly (yet).

Conclusion
Work with what makes you comfortable and never be afraid to try adopting new tools and services. If a new tool or service ever feels like it’s a chore, then you’re either using it wrong or it’s simply not a good fit for you.

It took me years to get to this type of setup as my needs have evolved. It works great for me but probably wouldn’t work for most people in this forum. For example, cost is very important for some so their development workflow will always be done locally.

Note: I’ve tweaked your post title because it was a little too broad. Feel free to adjust it.

3

Yeah I read that article already actually. Seems like composer is just the future because you mentioned, although you can install manually like M1, you need to upgrade with composer… unless you remove with composer and then manually install the new version.

How does this work with source control such as git? Normally I will deploy new things to development branch/dev server and then after sufficient testing, pull on production.

If a package is installed on development branch and then I pull the code to production. Naturally here, the only thing I’m getting is code and no database changes. So will I still need to use composer to “initialize” the extension even on production?

Also, what are you doing for regular product import? Are you using default magento dataflow?
This was too slow for me on m1 because we need to update anywhere from 3k-7k records at a time.
Ultimately I bought urapidflow because default m1 import could take hours, where this took only a couple of minutes.

4

composer.json
Let’s say I install “Extension A” on my Development Server using Composer, it places an entry inside of a file in the root directory of Magento composer.json but installs all the actual files in a folder within the root directory called vendor.

vendor doesn’t get tracked by git, but composer.json does. So, when I do a git pull on the Production Server, it only pulls across the file changes in composer.json. The next time I run a composer update command, it sees that I have a new entry in the file which in turn install the extension in the vendor folder. - God I hope this makes sense.

Tracking database changes
As for tracking database changes relating to post-installation settings, my workflow doesn’t account for that. If I build/install something new and start tweaking the settings then I simply put both browsers next to each other and copy the settings on the day of deployment.

Importing Product
I’m just using the default Import tool because it’s fit for our 2,000ish SKUs. It’s definitely better on M2 but you might still benefit from using a 3rd party extension if that’s what you’re used too. But then again, we never add more than 50 SKUs per month so it’s hardly taxing on the system.