Drupal remains among the most powerful open-source CMS solution for building any kind of simple to complex websites environnement. Its main stregth is its strong community over the years enabling constant evolution of this CMS.
However, Drupal can tkae time to handle but this is the same for any CMS,  and despite its highly versatile cappabilities, each new change, but also every new core upgrade to handle can become a time-consumming issue.

My goal here is to provide straightforward tools and methods to install and setup a dual dev/pro environment with a single databse and 2 development folders on a distant server. In my case I would do this on ovh pro servers for the new version of the website papierlogik. This will be done through the following steps, intrducing the use of various tools, starting with an application like putty on windos for easily connecting through SSH to acess and control the server folders content:

Strategy: One Database*, Two Environments

The key is to have a single, canonical database for your production site and a separate database for your development site.

  1. Production Site: This is your live site that the public sees.

    • Use one of your four databases (let’s say, Database #1) for this site.

    • This site will be the “stable” version. All new features and changes are first developed elsewhere.

  2. Development Site: This is a private, non-public copy of your site where you test new features, updates, or content.

    • Use another one of your four databases (let’s say, Database #2) for this.

    • Create a separate folder on your server for this development site (e.g., dev_papierlogik.com or dev.papierlogik.com).* Unfortunately, you still need to dedicate 2 independant physical memories and databases in total from you server provider, while these are the same again at each new stable release and befor the next developments.

The Development Workflow:

  1. Work on the Development Site: When you want to make changes (new features, updates), you make them on your development site first. This is a safe environment where you can break things without affecting your live site.

  2. Synchronize Data: When you want to work on a new feature, you can “pull” a copy of the live production database into your development database. This ensures your development environment is using the latest real-world data.

  3. Deploy to Production: Once you are confident that your changes on the development site are working perfectly, you can “push” them to your production site. This is typically a two-step process:

    • Code Deployment: Use a tool like Git (or simply manually copy the files) to move the updated code from the dev folder to the prod folder.

    • Database Updates: If your changes require database changes, you can use a tool like Drush to run database updates on the production site. You can also export your development database and import it into your production database if you need to transfer new content.

1. The Role of Git, GitHub, and GitLab

 

  • Change History and Versioning: This is the primary purpose of Git. It tracks every change you make to your code. This means you can see who changed what, when, and why. You can easily revert to a previous version if something goes wrong.

  • Code Backup: A repository on GitHub or GitLab serves as a remote backup of your code. If your local computer’s hard drive fails, your entire codebase is safe in the cloud.

  • Team Collaboration: It allows multiple people to work on the same project simultaneously without overwriting each other’s work.

  • Deployment: Git is the backbone of most deployment strategies, allowing you to move your code from your local machine to your server with a few simple commands.

 

2. The Distinction: Code vs. Content

 

This is a crucial point:

  • Git manages your code: This includes all the files generated by Composer (core/, modules/, themes/, vendor/), your custom code, and configuration files.

  • Git does NOT manage your content: This includes your database (pages, users, settings) and user-uploaded files (sites/default/files/). These must be backed up separately.

 

3. Integrating Git with your New Drupal Environment

 

You can absolutely develop all this together. Here is a robust workflow that combines our previous steps with a professional Git setup.

Step-by-Step Workflow for a New Drupal Site (PLK)

Step A: Local Development Environment Setup

Before you touch the OVH server, you should be developing locally. This is a crucial professional practice.

  1. Install a local development tool: Use a tool like DDEV, Lando, or Docker to create a local web server environment on your computer. These tools will mimic your OVH server, allowing you to develop without affecting your live site.

  2. Install Drupal locally: Using the tool you chose, follow the same Composer commands we discussed to install a fresh Drupal 10 project on your computer.

 

Step B: Setting up the Git Repository

 

  1. Initialize Git: Open your terminal in your local PLK project folder and run:

    Bash

    git init

  2. Create a .gitignore file: This file tells Git which files to ignore (e.g., user-uploaded files, specific temporary files). Create a file named .gitignore in your project’s root with the following content:

    # Ignore user-uploaded files
/web/sites/*/files

# Ignore vendor directory (Composer manages this)
/vendor/

# Ignore site-specific configuration that should not be committed
/web/sites/*/settings.local.php
/web/sites/*/settings.php

  3. Initial Commit: Add your files and create your first commit:

    Bash
    git add .
    git commit -m "Initial commit of Drupal 10 project"

  4. Create a remote repository: Go to GitHub or GitLab and create a new, empty repository. Do not initialize it with a README.

  5. Connect and Push: Connect your local repository to the remote one by following the instructions provided by GitHub/GitLab. The commands will look something like this:

    Bash
    git remote add origin https://github.com/your-username/your-repo-name.git
    git push -u origin master

 

Step C: Deploying to OVH

  1. SSH to OVH: Connect to your OVH server via SSH.

  2. Install Git: Make sure Git is installed on your OVH server. If not, you may need to ask the support team.

  3. Clone your repository: Go to the parent directory where you want to create your PLK folder and run the git clone command to pull your project from GitHub/GitLab:

    Bash
    git clone https://github.com/your-username/your-repo-name.git PLK

    This will create the PLK directory with all your code.

  4. Install Composer dependencies: In the PLK folder on your server, run the Composer install command to download all the necessary modules and dependencies:

    Bash
    composer install

  5. Run the Drupal install: Follow the drush site:install command we outlined before to install Drupal on your new database.

 

Step D: The Continuous Workflow

  • Develop: Make changes locally on your computer.

  • Commit: Use git add . and git commit to save your changes with a descriptive message.

  • Push: Use git push to upload your changes to GitHub/GitLab.

  • Deploy: Connect to OVH via SSH, navigate to your PLK folder, and run git pull to fetch the latest changes.

  • Backup: Remember to back up your database and user files separately. Use drush sql-dump > backup.sql and an rsync command to copy your files folder.

This workflow is the foundation of modern web development and provides a professional way to manage your sites.

Experiencing Step A.1: Docker and DDEV Tools install

Since you want a quick and reliable setup and already have some familiarity with Docker, I would recommend starting with DDEV. Its simplicity for Drupal projects will allow you to focus on the website itself rather than the environment configuration.

 

Let’s Get Started with DDEV

 

  1. Install Docker: If you don’t already have it, download and install Docker Desktop for your operating system.
    I found it there: https://www.docker.com/products/docker-desktop/Downloaded ARM64 version for wndows on my side (503 Mo)

  2. Install DDEV: Follow the installation instructions for DDEV on their official website: https://ddev.readthedocs.io/en/stable/users/install/ddev-installation/

Once you have both Docker and DDEV installed, let me know, and we can move on to the next step: using Composer to set up your new Drupal project locally.

Note: I was still using at that time computers running on Win7, however I could not find any docker install for this discontinued OS. So the next will be for Window 11.