In this post, you will learn how to put up a developer, test or security copy of your online store on PrestaShop 1.6, 1.7 and 8.x on your own in 10 steps. A store copy gives you control over changes before they reach your customers, you can modify it without worrying about the functioning of the production store....
The service of making a professional developer copy of the PrestaShop store.
Implementation time: up to 5 working days
Production version is a store available to your customers, making active sales.
Development (dev) version
This is a copy of the store available only to administrators and employees. The development version is a 1:1 copy of your production store. They will use the copies for testing and implementing new features. With a professionally implemented developer version of PrestaShop, you will avoid SEO, security and content duplication issues.
Examples of using a developer copy of the store
- Install and test new modules before launching them in the production store.
- Introduce time-expansive development work without stopping the work of the store.
- Update PrestaShop store and modules.
- Updating PHP versions and other server components.
- Optimize the store.
- The dev version will allow you to carry out development work on the store without stopping operation.
- Dev version is password protected
- Dev version is not available for your customers
- Version dev is not visible to web robots.
GIT deployment service is optional and you will get it for free if you decide to deploy developer copy.
The GIT version control system is responsible for tracking and storing all changes to your store's code and files. GIT controls the quality and changes to the code and is responsible for safely merging changes from multiple developers.
We recommend implementing a GIT version control system if more than 1 developer is working on your store.
- Git contains at least two branches containing the store's code - the development version and the production version.
- Git automates the implementation of source code changes and synchronization of dev > prod versions.
By opting for the GIT system, file editing via FTP will be limited. You can quit GIT at any time and go back to working with FTP. Returning to work with GIT again is possible, but requires synchronization of repositories.
Choose whether you want to use:
- Git hosted on your own server or on an external server.
- Free or paid GIT admin panel: GitLab or GitHub
- The developer introduces new functionality or fixes bugs and sends the changes to GitLab, to the dev branch.
- The changes are visible in the test version of the store, e.g. dev.yourjadomena.com
- The test person checks the changes. If the new features are not done correctly the test person sends a ticket to the developer, and the development process returns to step 1.
- Once the changes are approved, the 1-click test person creates a Merge Request - a request to move the changes from the development version to the production version of the store.
- Once the Merge Request is approved, GIT sends the changes from the development version to the production version of the store.
- To achieve maximum quality, we recommend implementing the versioning system on a serverac with full root access - such as a VPS or dedicated server.
- To operate GIT, we recommend free tools with a convenient admin panel: GitLab or GitHub.
- FTP servers often have limitations that slow down the GIT system.
Poprowadź bloga również w swoim sklepie