Implement CI/CD process

[hosungsmsft]

We should have a CI/CD process that validates every PR for best practices and template deployment correctness. A CI/CD process for our repo should also handle the pre-commit checks mentioned in #7. It'll probably closely follow what Azure/azure-quickstart-templates is doing, especially with their Travis CI process. With the latest azuredeploy.parameters.json and added options (MS SQL, optional redis, optional elastic search, ...) a test deployment should be possible within reasonable amount of time (about 30 minutes).

For an example CI/CD build on the Azure/azure-quickstart-template repo, see this (a PR from myself to integrate our changes in Azure/Moodle to Azure/azure-quickstart-templates repo) and the actual Travis CI build logs (can be accessed from the PR link by clicking the "Show All Checks" link and then clicking the "Details" link for continuous-integration/travis-ci/pr item.

[hosungsmsft]

Discussion results:

• 2 CI processes for different scenarios
  • One for any_fork/Moodle:any_branch to Azure/Moodle:develop
  • Just do some basic linting, syntax checking, fork/repo:branch naming checking
    • Runs on every PR from any external contributors (of course within Azure/Moodle as well)
• The other for Azure/Moodle:develop to Azure/Moodle:master
  • We do the ARM template validation ('az group deployment validate ...' -- this is very cheap and best be done in the above, but this even requires Azure credentials, so...) and actual ARM template test deployment ('az group deployment create ...').
    • This test deployment should not only check if ARM returned successfully, but also check if the deployed site is reachable and functioning.
    • We might even run some automated short load testing to the deployed Moodle site with our existing load testing scripts.
  • This can be triggered manually when merging Azure/Moodle:develop to Azure/Moodle:master, or periodically (e.g., daily).

We can still use Travis CI, and probably minimize our compute cost for the test deployments and load testing as well.

[mattporritt]

@hosungs
There has been work done on this that you can see in progress here: https://github.com/catalyst/Azure_moodle/tree/issue72_travis-ci

For any fork or pull request linting of the templates is done. This also includes code styling. Both Styling and Linting is done via JS hint.

If the correct Environment variables are set in Travis CI for the repository, the stack template is also validated and deployed (including Moodle) using the Azure CLI. The created stack is removed as part of the script clean up. So even on failure there are no resources left in Azure to cost money. This also means that individual developers can use their own Azure accounts for testing prior to a pull request if they want.

A good place to start is the .travis.yml file to see how things are done.

It is now looking like we will need to switch from the Azure CLI tools to the Python Azure SDK, in order to achieve the requirement. Notably we need to capture the output of the az group deployment create command, parse it and extract relevant Moodle details so we can test that Moodle was actually setup and operational. This is going to be easier than wrestling the output of the CLI using Bash.

Another issue that will be solved by moving from the Azure CLI to the Python SDK. If logging is set to minimal for the create process, Travis can time out the process as there are steps that don't output anything for more than 10minutes. Travis treats this as a failure condition. If logging is set to be verbose, the create process outputs more than 4MB of console output. Travis treats this as a failure condition.

[hosungsmsft]

Thanks @mattporritt for your detailed description. I'll go over your PR very soon, and I just wanted to mention what we discussed over the call yesterday. Switching to the Azure Python SDK is a good idea and I fully support it for future benefits. I also wanted to mention that if that switch takes longer than desired, we can keep using Azure CLI with the following alternatives:

• az group deployment create accepts the --no-wait flag that will make the command return immediately, not waiting for the long deployment operation to finish.
• Then we can use az group deployment show to periodically poll the status of the deployment and also extract the successful deployment's output (same as az group deployment create).

I understand that this will add some non-trivial logic (polling, breaking, ...) to the shell command, which better be done in a better programming environment like Python. Just mentioning this that we'd want to evaluate all the available options and pick the right and also the most efficient solution.

[hosungsmsft]

Sorry for not waiting for your Python SDK-based implementation, but I had to go ahead and implement the async initiation and periodic polling using bash anyway, as I was testing this CI from my side. Please see the latest master branch for the updates.