What are steps, guidelines and flows that needs to be followed for a successfully Magento2 Continuous Integration workflow ?
Magento – Magento2 CI Server Integration for Production
deploymentmagento2
Related Solutions
In fact, every day I am less convinced about the utility of Magento 2 production mode, unless you are not going to change anything in the project. Can you change my mind?
I'm not sure if I understand you correct, but that's exactly what the production mode is for: production systems where you do not change anything (code wise). Until the next deployment, that is.
I find the Git based deployment that you are using less suitable for Magento 2 than it was for Magento 1, because of all the preprocessing. The build and deployment is more complex and IMHO there is no way around an automated build process
What I would recommend:
- Have repeatable deployments, i.e. you should be sure that the exact same code ends up in production that was in staging, including generated files.
To achieve that, separate build from deployment and do the following in the build process:
composer install
(addingvendor
to the repository instead is possible too, but if you did that just to avoid running composer on the server during deployment, rather do it in the build step and only keepcomposer.lock
in the repo)Code generation (YMMV):
bin/magento setup:di:compile bin/magento setup:static-content:deploy
create an archive (the build artifact) from the full Magento directory, excluding
media
andvar
, but includingvendor
,pub
,var/generated
andvar/di
. Starting with magento-2.2,var/generated
andvar/di
are moved togenerated/code
andgenerated/metadata
, which makes it easier to separate them from the rest ofvar
which should be ignored for deployments.
In the deployment, copy the build artifact to the target server, extract it to a new directory and:
- link persistent directories into it (
media
,var/session
,var/log
, ...) - enable maintenance mode
- switch document root (usually the docroot is a symlink to the last release, change it to the new release)
- flush cache
- run
setup:upgrade
- disable maintenance mode
- link persistent directories into it (
This deployment process can be easily implemented with Deployer, which is like Capistrano but in PHP. A full deployment solution for Magento 2 based on deployer can be found here: https://github.com/mwr/magedeploy2 (thanks to netz98!) and here is another one that we use: https://github.com/staempfli/magento2-deployment-tool
- Keeping
app/etc/config.php
in the repository is good to keep track of enabled and disabled modules.
This is not a step by step instruction but it should give you an overview for a more robust alternative to your current process. Take a look at the linked tools to see how a full solution may look like.
You cannot run the core test suite with a customized build like this. But this is not their purpose anyways. The core integration test suite is there to ensure that the core modules work together as intended and to prevent bugs in Magento itself.
If you want to run an integration test for the checkout that is adapted to your changes, you are free to reuse parts of the core tests, but you will have to make adjustments like adding values for custom required attributes in the used fixtures.
But do not try to recreate integration tests just for core functionality. Create tests that ensure, that your code works.
For high level "Magento still works" tests, functional tests are more appropiate than integration tests. That's also why the new Magento Functional Test Framework (MFTF) will give us extensible core tests. This one is meant to be run on custom builds.
Best Answer
We're currently working on improving our deployment process in Magento 2. I'd welcome any feedback you have - please ping me on Twitter or email.
Right now on M2 you'd do the following (in your environment)
FYI set:mode production does a
There are some other approaches you can use now to get closer to a 2 step build and deploy process but they're rather complex.