Enterprise & DevOps

Interview Questions: CI/CD, Scaling, and High Availability

Q1: How do you handle Moodle deployments in a load-balanced environment?

In a load-balanced environment (multiple web servers), you must ensure:

  • Code Consistency: All servers must run the exact same code version (use Git or immutable artifacts).
  • Shared Dataroot: moodledata must be on a shared file system (NFS, EFS, or GlusterFS) so all nodes can access files.
  • Centralized Cache: Use Redis or Memcached for MUC (Moodle Universal Cache) and Sessions, so users don't lose session data when switching nodes.
  • Database: Use a separate database server (or cluster), not localhost.

Q2: What is the difference between `git pull` and a proper CI/CD pipeline for Moodle?

Git Pull: Risky on production. Can leave the site in a broken state if merge conflicts occur or if dependencies (composer/npm) aren't updated. It also keeps `.git` metadata on the server (security risk).

CI/CD Pipeline: Builds the artifact in a safe environment (runs tests, compiles SCSS/JS, installs vendor deps), and deploys the ready-to-run code to production. It ensures zero downtime (with blue/green deployment) and rollback capabilities.

Q3: How do you upgrade a massive Moodle site (1TB+ DB) with minimal downtime?

Standard upgrades can take hours. Strategies to minimize downtime:

  • Test Upgrade: Always run a dry run on a staging copy to measure time and catch errors.
  • CLI Upgrade: Always use php admin/cli/upgrade.php instead of the web UI (avoids timeouts).
  • Delta Migration: If migrating servers, sync the bulk of data while the site is live, then do a final "catch-up" sync during a short maintenance window.
  • Parallel Processing: Some database schema changes can be run in parallel if you know what you are doing (advanced).

Q4: Explain the role of Redis in a high-performance Moodle setup.

Redis is an in-memory data structure store used for:

  • Application Cache (MUC): Stores configuration, language strings, and database schema info to reduce DB hits.
  • Session Cache: Stores user sessions. Essential for load balancing (sticky sessions are not reliable enough).

Configuration in config.php:

$CFG->session_handler_class = '\core\session\redis';
$CFG->session_redis_host = '127.0.0.1';

Q5: What is "Cron" in Moodle and why is it critical?

The Cron script (admin/cli/cron.php) is the heartbeat of Moodle. It processes:

  • Forum email notifications.
  • Course completion calculations.
  • Assignment grading workflows.
  • System cleanup (temp files, old sessions).

If Cron stops, the site may appear to work, but emails won't send and students won't get grades. It should run every minute.

Q6: How do you automate testing for a custom Moodle plugin?

We use two main tools:

  • PHPUnit: For backend logic (classes, functions). Requires a separate test database.
  • Behat: For frontend/acceptance testing. Simulates a user clicking through the site.

These should be run in a CI pipeline (GitHub Actions / Jenkins) on every commit.

Q7: What are "Adhoc Tasks" vs "Scheduled Tasks"?

Scheduled Tasks: Run on a regular schedule (e.g., "Every day at 2 AM"). Defined in db/tasks.php.

Adhoc Tasks: One-off background jobs created dynamically by code (e.g., "Process this specific video file now"). They are picked up by the cron as soon as possible. Better for performance than doing heavy work during a user's HTTP request.

Q8: How do you secure `moodledata`?

1. Location: It must be located outside the web root (public_html) so files cannot be accessed directly via URL.

2. Permissions: The web server user (www-data) needs read/write access, but other users should have none.

3. Execution: Prevent script execution in this directory (e.g., no .php files should run from here).