There is no doubt that Magento 2 as a platform is more technically challenging for all parties involved. However, complexity isn’t always a bad thing. If you have the correct processes in place, you may not notice the complexity at all. One key area that can alleviate a lot of pressure is development environments. Expecting frontend and backend developers to set up a full stack on their local machine is not only unrealistic but also extremely insecure and inefficient.
This, unfortunately, is the method used by most developers and development houses. This method is where a developer will develop on their local machine. This requires the developer to set up a full working Magento 2 stack, including; getting code/database backups, configuring the webserver, importing databases. When starting work on a new project this initial setup can take up to a full working day. Once the developer is set up and running, they will then develop on their own machine, where only they can see and test their changes. When they feel the work is complete they will then commit (store) their changes. These changes will then need to be pulled onto a staging server where it can be tested, this again is usually another manual process.
>This is a relatively new method, the concept has been around for a while but hasn’t been technically feasible. The developer will develop on a remote server, either through a web-based IDE or via sftp/nfs. This keeps the actual development process the same. Because the environment where the project is running is on a remote server this allows the environments to be preconfigured. Not only this, but they can be ready in minutes. So the developer gets an optimally configured environment and they can begin developing in minutes. It also allows other developers/testers/project managers to actually see the current progress without any extra action.
>There are many ways to compare the two options, but we feel the main ones are...
Local development - This requires every developer to have a copy of the database on their computer, which from a security standpoint is less than ideal. Not only this, but also the process for creating the backup and distributing it to your developers is a complicated task when trying to maintain security. Remote development - This requires a single backup, which only authenticated users have access to. In addition, most platforms offer sanitised backups, which remove any sensitive information from the backup.
Local development - Every developer requires a computer capable of running the platform in a usable manner. Remote development - Developers on need a computer that is capable of running a web browser. Further reducing the capital required to get a developer up and running.
Local development - Every developer must set up a working copy of the project they are working on before they can even start developing. This in many cases can be a least 1 day. Any additional tools needed to debug issues take further time to install and configure. Remote development - The environment can be created by a non-developer / webhook so the developer can start work immediately. In addition, all debug tools are already installed and available to the developer.
Local development - To test the developer’s work or get an update on progress this work must be pushed to a staging environment or viewed on the developer’s actual machine. Remote development - The current progress of any task can easily be seen and tested in place without any additional work.
From looking at the comparison points we can clearly see that remote development offers so many advantages that it can’t be ignored. The only issue is finding a remote development environment for the platform you are working on. Fortunately, if you are working on Magento 1 or Magento 2 there is already an answer, MDOQ.
>There is no doubt that Magento 2 as a platform is more technically challenging for all parties involved. However, complexity isn’t always a bad thing. If you have the correct processes in place, you may not notice the complexity at all. One key area that can alleviate a lot of pressure is development environments. Expecting frontend and backend developers to set up a full stack on their local machine is not only unrealistic but also extremely insecure and inefficient.
This, unfortunately, is the method used by most developers and development houses. This method is where a developer will develop on their local machine. This requires the developer to set up a full working Magento 2 stack, including; getting code/database backups, configuring the webserver, importing databases. When starting work on a new project this initial setup can take up to a full working day. Once the developer is set up and running, they will then develop on their own machine, where only they can see and test their changes. When they feel the work is complete they will then commit (store) their changes. These changes will then need to be pulled onto a staging server where it can be tested, this again is usually another manual process.
>This is a relatively new method, the concept has been around for a while but hasn’t been technically feasible. The developer will develop on a remote server, either through a web-based IDE or via sftp/nfs. This keeps the actual development process the same. Because the environment where the project is running is on a remote server this allows the environments to be preconfigured. Not only this, but they can be ready in minutes. So the developer gets an optimally configured environment and they can begin developing in minutes. It also allows other developers/testers/project managers to actually see the current progress without any extra action.
>There are many ways to compare the two options, but we feel the main ones are...
Local development - This requires every developer to have a copy of the database on their computer, which from a security standpoint is less than ideal. Not only this, but also the process for creating the backup and distributing it to your developers is a complicated task when trying to maintain security. Remote development - This requires a single backup, which only authenticated users have access to. In addition, most platforms offer sanitised backups, which remove any sensitive information from the backup.
Local development - Every developer requires a computer capable of running the platform in a usable manner. Remote development - Developers on need a computer that is capable of running a web browser. Further reducing the capital required to get a developer up and running.
Local development - Every developer must set up a working copy of the project they are working on before they can even start developing. This in many cases can be a least 1 day. Any additional tools needed to debug issues take further time to install and configure. Remote development - The environment can be created by a non-developer / webhook so the developer can start work immediately. In addition, all debug tools are already installed and available to the developer.
Local development - To test the developer’s work or get an update on progress this work must be pushed to a staging environment or viewed on the developer’s actual machine. Remote development - The current progress of any task can easily be seen and tested in place without any additional work.
From looking at the comparison points we can clearly see that remote development offers so many advantages that it can’t be ignored. The only issue is finding a remote development environment for the platform you are working on. Fortunately, if you are working on Magento 1 or Magento 2 there is already an answer, MDOQ.
>