Child pages
  • [deployment] Store deployment log in the database [5.3.0-B1]
Skip to end of metadata
Go to start of metadata

Right now deployment script writes execution log in large text file, located in "/system/project_upgrades.log" and remembers deployed revisions in AppliedDBRevisions column in Modules table.

I'm proposing to create new ModuleDeployment table to ease deployment process reviewing. Table would have following columns:

  • Id
  • Module - name of module, revision belongs to
  • RevisionNumber - deployed revision number
  • RevisionTitle - title of revision from project_upgrades.sql
  • CreatedOn - when revision was deployed
  • IPAddress - who deployed a revision
  • Output - deployment messages
  • ErrorMessage - error message, that happened during deployment process
  • Status - deployment status (deployed normally, deployed with errors, synced)

And we can add "Deployment" tab in Modules list (no need to edit a module to see it's deployments).

 

P.S.

This would replace existing functionality, because it provides easier access and control over that data.

Related Tasks

INP-1274 - Getting issue details... STATUS

3 Comments

  1. Today I had a serious problem with fact, that we have a deployment log in a file and not a database. I was in a situation, where 3 sql queries from project_upgrades.sql file were not executed, but their revisions were marked as being executed successfully in database. However in /system/.restricted/project_upgrades.log file these 3 sql queries were missing for sure. Also format of that log itself didn't provided any intel on what actually happened.

    Since all revisions which were even deployed or synced are stored as command-separated list without deployed/synced status in Modules.AppliedDBRevisions table, then we even don't have an info to investigate a problem in first place.

    CC: Dmitry Andrejev [Intechnic]

  2. I fully support this idea. Let's create a task for this in 5.3.0 describing what we are doing and how.