This article is aimed at developers and agencies looking to integrate MDOQ into their current workflow. We understand that just because we love MDOQ and wouldn't do any work with Magento elsewhere you/your developers may not... Yet!
We will go through a couple of common examples and suggestions on how you can incrementally incorporate MDOQ into your Magento development workflow.
(This article assumes you have at least 1 production instance on MDOQ that may or may not be live yet)
1. Replace your staging site
We believe the best first step is to replace any current staging environment with an MDOQ release candidate instance. (These are designed to be a target for multiple pieces of work.)
Why?
A staging site is common pain point, where a lot of time is spent in keeping it up to date as well as performing releases / staging cut overs. By replacing it with an MDOQ instance, all people involved with the development are able to see an instant time saving:
- Developers aren't need to keep the site up to date or to perform releases
- Tester/QA don't need to chase developers to test and approve work
- Clients can use the same links to access the release candidate allowing them to see current progress and approve changes as often as they like
- Project Managers don't need to schedule developer resource to get work into an accessible environment
- Anybody within the business can perform releases to the staging environment.
How?
If your developers are still working locally and you don't want to force a shift MDOQ immediately. So long as your current process involves the developers merging their work into a common branch (for example staging, pre_production, release_candidate) then you/anyone can simply pull this work in on an ad-hoc or regular basis
Ad-Hoc
Once you know there are changes in the branch that aren't on the instance
- Sync Code (Sync > check "Code" > Click "Synchronize")
- Once complete, put the instance into production mode (Toolbelt > Actions > Deploy Mode > "Production"
Regular
If you don't want to manually handle this process, you may choose to pull changes in nightly.
The steps are the same as above, however you and use the MDOQ API to run these actions, which you can add to as a cronjob to any server.
(If you're interested in this please get in touch with us)
Taking work to production
Once the work has been approved on the release candidate instance, anyone can simply use the "Author Release" process to take the work live. (see Getting Started using MDOQ)
2. Replace/Add QA site(s)
Depending on your current process, you may or may not want to test, validate and approve work in isolation. However using MDOQ development instances is an easy way for a developer to hand off their work to QA once they believe it is ready.
Why?
Again this is another common pain point, the developer has completed the work on their machine. But then has to push to a staging for it to be tested. Which may not be available right away if there is already work on staging that is under review. This can cause a lot of wasted time where work is sat waiting to be ready to be reviewed. If enough time has passed since the developer completed the and an issue is found it can take extra time for the developer to fix as they have re-pick up all the context around the work they carried out.
How?
So long as the developer has carried out work in a stand alone branch, you simply need to create a development instance with a ticket number the same as the branch name. MDOQ will then roll the instance up from this branch. Once complete the work can be tested and approved in isolation.
If issues are found and the developer carries out more work locally, then pushes to the git branch you can follow the same steps as for the release candidate instance to pull this onto the development instance.
- Sync Code (Sync > check "Code" > Click "Synchronize")
- Once complete, put the instance into production mode (Toolbelt > Actions > Deploy Mode > "Production"
Work approved
Once the work has been approved on the development instance, you have two options
Merge work into release candidate
To do this during the "I'm Done" process select the release candidate branch and MDOQ will merge to that branch
Take the work to production
To do this during the "I'm Done" process select the branch that is configured as your "main branch" MDOQ will merge to that branch and also create a deployment that can be deployed to production.
(see Getting Started using MDOQ)
3. New/Junior or nominated Developers
The next step to integrating MDOQ into your workflow would be to nominate some developers to work only on MDOQ instances (not on local Magento stacks).
Why?
- Setting up a development environment for Magento is a long, difficult and error prone process and rarely does the stack you end up with match the production environment, which introduces risk.
- Equally having a developer, or requesting a senior developer to fetch MySQL backups from production, introduces risk of backups being accidentally leaked/stolen and it takes human time.
- If the local environment breaks they need to resolve before any work can take place
- Some clients have nuanced set up, which is another thing the developer needs to be up to speed with.
- All this time is very rarely something the client is willing/wanting to pay for.
How?
Before any work begins, create a development instance. (This can be carried out by a project manager the day before the task is due to be started, ensuring it's available as soon as the developer is.)
The developer can then work on the instance to carry out the development. There are many options on how they can do this detailed here.
As soon as the developer believes they are done. they can use the "I'm Done" process to put the instance into "Client Acceptance" state. At this point they can hand over to QA/Client/PM for review and start another task.
(see Getting Started using MDOQ)
Work approved
Once the work has been approved on the development instance, you have the same options as Replace/Add QA Site(s).
4. More Developers!
By monitoring the burn rate, time to complete, time to release for the work carried out by the nominated developer(s) you will see that they are more productive. They should also have more time to do the work they want to do and not be getting bogged down with managing local environments, making their lives/job easier.
With this in mind, you should nominate more and more developers to be 100% MDOQ focused. The pace at which you choose to this is up to you.