Background
Magento solutions get bigger and more complex, at least here at Eepohs. Magento development requires multiple displines like Frontend Development (JS, CSS, HTML, XML etc), Backend Development (PHP, JS, XML etc), System Integration (JSON, XML, REST, SOAP, (s)FTP etc…). So it’s quite obvious that Magento development is rather teamwork than a play of single freelancers. Freelancers can take your solution to some limit but sooner or later you need to hire a team that can support solution and take it further on.
Tools
There are a couple of tools that are crucial for teamwork and especially important when your team is not sitting together but is distributed in the room and possibly in time also. The tools for successful teamwork are:
– issue management tool – JIRA
– version control tool – GIT
When you have more than 1 developer you need a process. In fact you’d need a process when you’re working alone, too but it’s not that stringent in this case.
You have several processes while doing development:
– version control process and strategy
– issue management process
– general workflow
– development itself – writing code, chasing bugs, debugging etc.
– quality assurance (QA)
– deployment process
You have several processes while doing development:
– version control process and strategy
– issue management process
– general workflow
– development itself – writing code, chasing bugs, debugging etc.
– quality assurance (QA)
– deployment process
The latter seems to be quite tough because there’s a lot to be deployed between different stages and instances.
There are 4 stages (and n different Magento instances in each) in Magento development cycle
– development (local developer machine, local server)
– testing (internal testing by the QA team)
– staging or pre-live (pre-live testing by the QA team and the customer)
– live
 |
| Deployment of changes |
A note about popular alternative – Subversion
Subversion is not good for Magento development for 2 reasons:
- it must be connected to central server. So you cannot version your files while working offline
- svn creates its own special control folder .svn with a lot of extra files inside every folder in Magento. Magento codebase is huge and svn creates a very big extra overhead for your filesystem. It makes it painfully slow and tedious.
- … I won’t start rant about merging in svn and git here…:)
- And yes – I have used svn, A LOT. So I know what I’m talking about:)
Magento specific issues a.k.a the Bad News
Attribute sets and attributes
How to manage attribute set and attribute migration between 4 stages described above?
The 2 above are actually quite simple to resolve. Magento offers excellent tools for that – install/update scripts. Just add your attributes and sets via install/update scripts and they will get to all environments automatically when code is deployed there.
Stores and Content
Store is the most crucial entity. Everything is depending on that, even configuration and content.
Configuration
That’s a tough one. How to version configuration? How to move conf changes from one Magento to the other?
Magento Deployment tools a.k.a the Good News
There’s a cure for all these issues above, though… I’ll shed some light to available tools in the upcoming posts.
