So you receive a Magento request from a new customer. Great! You have a first look at the server. So far so good! You quickly realise that there is no version control system (VCS) and no separation of customisations and core code. DAMN IT!!! Q(/%LJx§“?8SA?!(&%!!! I can of course only tell from my experiences, but I have the impression that this problem is absolutely common and happens with shops of any size. So how do you convince your new potential customer to initially spend a fair amount of money to just bring his project technically on a good basis? He does not have any direct advantages from it. But which advantages can you promise anyway, which may convince him?
What are advantages of introducing a VCS like git or Subversion (with an extreme preference for git)?
- Bad changes can be reverted: Sometimes developers implement a cool feature or try to fix a bug and once it is live, you soon realise that it does not work at all and that the recent changes have to be reverted. You have nearly no chance if you do not have a VCS and changes have been made at various places. With a VCS in place, you simply deploy an older version or revert your recent changes.
Advantage for you as a customer: You get some kind of security and backup „for free“. - Mistakenly deleted code can be recovered: So your developer deleted some code because he thought it is not needed or because you even said that you do not need it any more. A few weeks later, you realise that you definitely need the feature which has been deleted. Pity, you have to pay your developer to implement the feature again. If there is a VCS, he can simply add the deleted code again with a few clicks/commands.
Advantage for you as a customer: You simply save money. - It is visible who made which changes: If multiple developers work on a project, the VCS ensures that developer A can see that feature X has been developed by developer B. Hence, he can directly ask the correct person about the code, so that the development becomes faster. And you can of course blame the developer who introduced a certain bug 😉
Advantage for you as a customer: You again simply save money.
What are advantages of separating your customisations (namely extensions and themes) from the core code?
- Properly deleting an extension is just one click: Required functions vary from time to time. In a few years, you probably do not need a lot of extensions any more, but use others instead. With a proper separation, your developer simply needs to delete one folder in order to uninstall an old extension.
Advantage for you as a customer: You simply save money. - It is directly visible which customisations are in place: If the customisations are tangled with the core code, a developer does not have a good overview of the system. He does not know which customisations have been made and what each extension really does. With something like modman, he can directly see which extensions are installed and can directly see all files that come with a certain extension.
Advantage for you as a customer: Your developer needs less time to incorporate and makes less errors – which again saves you money. - Upgrading extensions or the core is less work: If there is no separation of customisations and core code, upgrading an extension or Magento is tedious, because you have to check if there are any files which are no longer needed by the extension or Magento itself. Additionally, you have to replace all the files if there is a Magento upgrade. If you have a proper separation, upgrading is as easy as exchanging one folder.
Advantage for you as a customer: You again simply save money.
Are you a customer who hires Magento developers? If you read the whole post, you probably realised that besides of getting a more secure environment, you simply save money in the long run, because development is much easier once the initial setup is done.
Are you a Magento developer yourself? How do you handle the explained issue? Do you know of any more advantages? Do you generally charge some setup costs? Let me know in the comments!
Although I mentioned modman in the title, you can of course also use composer or something alike. This is nothing about the tool, this is something about separating customisations from core code.
Regarding version control, I explain that I won’t touch any line of code that is not under version control. It’s usually easy to convince customers how this is important and the initial cost is not high anyway (yes, it’s going to be charged).
With modman/composer I am not so strict. Especially with many existing modules, converting all of them to modman is lot’s of initial work and error-prone, so I prefer a hybrid solution as described in http://www.integer-net.de/magento-entwicklung-mit-vagrant-teil-3-projektstrukturen-fuer-magento/ („Alternative 3“). This way I still can convert exising code on an as-required base (i.e. as soon as it has to be changed/updated). This will be charged as part of the respective change/update, so the customer doesn’t see one big expense for introduction of modman, it just happens over time.
Interesting approach, thanks for sharing!