Child pages
  • [deployment] Using file-per-revision for Deployment Script
Skip to end of metadata
Go to start of metadata

To minify conflicts during parallel project development by different people I propose, that we:

  1. create separate file for each deployment script revision
  2. make filename consist of date (and time optionally) + task number + optional explanatory text
  3. support for PHP script if present and named the same

I know this can lead up to 80+ files on average project, but in this scheme you have absolute 0 of conflicts due fact, that every developer adds their revision to end of /modules/custom/install/project_upgrades.sql file and uses same revision too.

With this implemented we'll have /modules/custom/install/project_upgrades/ folder where all files will be placed. For example:

# revision created on "12 May 2013" for task number "34545"
2013-05-12.34545.optional-text.sql
2013-05-12.34545.optional-text.php

As mentioned before "option-text" part is completely optional and is only needed if developer makes 2+ commits for same task in same day. In such case adding explanatory short text is better, then adding commit time.

 

After a bit of thinking renaming "project_upgrades" folder into "patches" would make it more appropriate because we really have SQL queries, that patch DB to desired state and doesn't really upgrade it to another version as done with In-Portal releases.

Related Discussions

Related Tasks 

INP-1420 - Getting issue details... STATUS

4 Comments

  1. I have several questions here:

    1. What happens if I need to go back and add more work to the same task that already has SQL and/or PHP files create yesterday. Do I update the same file or create new files?
    2. Can 2 separate developers under ANY circumstances commit into the same SQL and/or PHP files? Let's say there 1 task (rarely but possible) that was used by 2 different people on the same date or one was helping another.
    3. I would stay away from "patches" terms since it's directly applies Patching some files and NOT the DB. I think "project_upgrades/" or "upgrade_files/" specifically says that what we are doing there - these files that upgrade the DB.

    Let's try think about all unusual cases that might raise here.

    In general I like the idea of less conflicts, but it's going to be painful to find and make sense of things through 80+ files - that's my only concern so far.

    1. What happens if I need to go back and add more work to the same task that already has SQL and/or PHP files create yesterday. Do I update the same file or create new files?

      Of course we create new file. Right now we create new revision too, because someone might have already executed that revision and won't catch our update otherwise.

      Can 2 separate developers under ANY circumstances commit into the same SQL and/or PHP files?

      Nope. These files must not be changed once commited. But specially for that I've allowed username or short change description to be added to filename too. This way no conflicting filename will be used.

      I would stay away from "patches" terms since it's directly applies Patching some files and NOT the DB.

      Database is patched through SQLs files. That might be a bit confusing at first. Maybe "db_patches" or "db_upgrades" would sound better.

  2. Gleb Sinkovskiy [Intechnic] proposed following format YYYYMMDD-HHMM-TASK_NUMBER.sql. For example: 20140411-1715-12345.sql.

  3. Since we're also combining upgrade system with deployment system the following would be done:

    Folder structure:

    {module}/install/upgrades
    {module}/install/upgrades/parameters.json
    {module}/install/upgrades/sub-folder1
    {module}/install/upgrades/sub-folder1/YYMMDD.task-code.php
    {module}/install/upgrades/sub-folder1/YYMMDD.task-code.sql
    {module}/install/upgrades/sub-folder1/parameters.json
    {module}/install/upgrades/sub-folder2

    Rules:

    • the "changeset" term is group if file with same name, but different extension (e.g. php/sql)
    • the "changeset group" term is a sub-folder within {module}/install/upgrades folder
    • changesets within a group are sorted chronologically
    • changeset groups are sorted in 2 modes:
      • chronologically (changeset group folder must be named as date, e.g. "Mar-2014")
      • by version (changeset group folder must be named as version, e.g. 5.2.1-B3)
    • changeset group can depend on another changeset group
    • the "{module}/install/upgrades/parameters.json" file contains settings to configure module-specific upgrade logic:
      • sorting: version/date
    • the "{module}/install/upgrades/sub-folder1/parameters.json" contains settings of "sub-folder1" changeset group within "{module}" module:
      • dependencies: list of another module/changeset groups, e.g. ["in-link:5.4.1", "in-portal:4.0.0"]

    How to use:

    • build large graph from all modules (including core) based on their dependencies
    • if changeset group has no dependencies, then put it at the end of list

    TODO:

     Find a way how to track applies changesets and changeset groups knowing, that:

    • for In-Portal once changeset group was applied, then it can't be changed
    • for Projects more changesets will be added to changeset group