Getting Started using MDOQ

This introduction on getting started with MDOQ explains the key pillars in developing with MDOQ.

1. Create an instance and carry out some work - with a basic understanding of git, this can become quickly familiar and have you developing and deploying code quickly. Key activities when developing on an instance are:
   - Creating a new instance
   - Merge master into your branch - this ensures that other work carried out by other developers, is merged into your branch. Please ensure you then 'Git Pull' to pull the code to the instance.
   
   
2. Push your work - Click the GitHub icon, then ‘Git Push’ - this will do a dry-run and list all files which have changed. Here you can select only the files you know you have changed. This can sometimes suggest changes might be required to .gitignore but effectively just allows MDOQ to help you commit and push work to the associated branch.
   
   
3. Im Done (Deployment Preparation) - Click ‘I’m Done’ and select master (you need to make sure you have completed step 1 here otherwise it will report “This branch is behind master” otherwise you can proceed. This process will rebuild, test and then leave the instance at a point where you or anyone else can test it fully. After the automation completes you will see 2 buttons replace the ‘Im Done’ button, to either accept or decline. Please click accordingly. Don’t worry this does not yet deploy to production, follow the procedure and allow the system to select a new tag and this will tag and prepare a ‘deployment’ for the last stage
   
   
4. Deployment - If there is an outstanding deployment available you can now use the deployment pipeline. Select the production instance (blue tabbed instance usually top instance on the left), then ‘PERFORM RELEASE’ this carries out all the necessary checks for the current release, any available new releases (after you have performed 1,2,3 above) and you can safely deploy. Please note, Zero Downtime Deployment can be used if you know that there are no upgraded modules or changes to app/etc/config.php, Force Git Checkout is some-times needed but should only be if someone has changed files on the production server outside source control.