Developing Remotely - the future of Magento Development
It would be hard to argue that the Covid has certainly accelerated the topic of remote development. Not just with Magento, but as with all web applications, the complexity and evolution of the ‘stack’ gets increasingly more complex.
If you do not adopt IaC practices then as a developer you are simply delivering a more costly service. If you are a developer working for one Magento merchant on 1 project, then some of the benefits of using RDE’s lessen, however even then, when you involve collaboration and increased geographical disparity in your team, then locally developed work packages simply don’t offer value.
Case 1 - small work package
If you have a 4 hour piece of work to deliver a small functional improvement to a Magento store, then in many cases in order to facilitate your local development, you will have a number of hours work in setting up your local environment before you can start work. Others (whom are steadfast in using local development) might argue that there are scripts and automations to speed up this process, however, these are not standardised.
Case 2 - large merchant with QA team
Often not considered (from the development viewpoint) are the drawbacks involved from the end of the programmers job, to get the code to production. Usually, in order to gain acceptance and pass quality assurance, you might have staff at other locations. If you need to move on to another piece of work and your QA department cannot quickly and easily provide acceptance, then again you need to facilitate different hardware to push your work before your time is available for the next programming task. Again this carries a cost implication and if you do not have multiple staging servers then again the typical developer bottlenecks soon start to impede development.
Case 3 - team members in other locations and time-zone
This case almost definitely requires multiple, separate staging instances in order to streamline your team’s development processes. Adobe Commerce Cloud can facilitate this however this carries a cost.
Case 2 - collaborative work package
Often not considered (from the development viewpoint) are the drawbacks involved from the end of the programmers job, to get the code to production. Usually, in order to gain acceptance, QA, possibly even collaborate with one or more developers, stake-holders, etc, they cannot access your local development instance, therefore you are faced with a final committal to another server and process to get your work to a staging server. At this point, this work might be reviewed/considered the loopback for change/iteration or simply the evolution of an idea, carries a cost. The developer might be on another project and therefore to re-instate this piece of work will
Adobe - Sorry, you are Wrong!
There is an impending kick-back from the original Magento Community around many topics not least the loss of online content around the ‘Magento’ platform. Therefore if you search for Optimal Development Environment for Magento then you are likely to find yourself here https://devdocs.magento.com/guides/v2.4/extension-dev-guide/build/optimal-dev-environment.html
It's hardly surprising since the authority of the site remains high however 'Optimal' is certainly not a suitable word I would have used. This article provides opinions warped towards much larger merchants and obviously Commerce (license payers) but in our opinion it is outdated and should at very least be providing acknowledgement to the massive benefits of IaC, CaC and RDE's for merchants of all sizes.
Comparing different Magento Development strategies from a business perspective
It's fair to say that since Magento 2, there is a distinct lack of business-led content on Magento. This needs to change, otherwise smaller merchants get the wrong message, that Magento is really only for large businesses and this, once vibrant Open Source eco-system is being sat on by the mighty Adobe. This is simply not the case and this is just one small use-case demonstrating how wrong adobe
Option 1, Adobe’s Recommendation
Local dev machine > QA/integration server > Preview server (optional) > Production server
OK so the above has potentially 3 environments away from production. Don’t forget, if ANY issues are found in any environment (beyond the Local Dev) then the process loops back and reinitiates further instances. So as an example, if 1 piece of work has 2 feedback iterations and 3 bugs, then this is what happens.
Local Dev > QA > Preview server (client provides feedback/change request) > Local Dev > QA > Preview Server (client provides second round feedback) > Local Dev > QA (issues found with final deliverable) > Local Dev > QA > Preview Server > Finally ready for production
So following the Adobe recommendation, it’s possible you might need 11 instances of Magento in order to get this piece of work to production.
Option 2, Remote Development using Jetbrains Space, MDOQ or Gitpod
Remote Development Instance > Production server
Since the same single instance can be used/accessed persisted for an infinite, collaborative feedback loop, easily facilitating large teams, multiple locations, and time-zones, this decoupling of developer and environment means costs and timescales are slashed. Adopting IaC and CaC along with deployment pipelines this can once again renew faith in the platform that Magento Open Source is once again the world-leading platform for businesses of all sizes.