Child pages
  • [deployment] Show un-deployed revisions in "System Tools" section [5.3.0-B1]
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/d334e03e7bc28c10#

Section "Tools -> System Tools" have 2 buttons in it related to deploying process:

  • Synchronize - marks all non-deployed revisions deployed without actually deploying them (useful for revisions made by yourself, because it's SQLs are already executed manually)
  • Deploy - deploys revisions, imports language pack and rebuilds all sort of caches

However what if developer forgot to click on Synchronize button before doing an update from VCS and now have a mix of un-deployed revisions from his own and other developer made revisions. In such situation clicking on Deploy button will most likely cause SQL error if not worse.

I'm proposing to add more intel on "System Tools" page and display following:

  • Revision statistics (e.g. "Deployed 5 of 10 revisions")
  • List of not yet deployed revisions

Usually developers visit "System Tools" section at least once during task development and they will surely see that some revisions are required to be deployed. However they don't see if these revisions are made by them and are not yet commited to VCS or they came from other developers via VCS update.

Any ideas/suggestions?

Related Tasks

INP-1275 - Getting issue details... STATUS

10 Comments

  1. idea: each revision line could start with a checkbox, so developer could manually synchronize or deploy chosen ones :)

    Envoy

  2. Nice. Then interface will look like:

    === New Revisions ===
    [select all] [select none]
    [x] r41: #task_number1 - task description1
    [x] r45: #task_number2 - task description2

    === Synchronize ====
    description
    [button]

    === Deploy ===
    description
    [button]

    Text in "===" and "===" is heading. And we need to update description to
    tell, that only checked revisions will be affected by the
    Synchronize/Deploy button.

  3. I'd suggest:

    === VCS ===
    [select all] [select none]
    [x] r41: #task_number1 - task description1
    [x] r45: #task_number2 - task description2

    [Synchronize button] (?) --- [Deploy button] (?)

    with button action description hinted in "?". Why? Because admin read this once (or twice) in his life, so why wasting space with these infos?  

    Envoy

  4. Hi guys,

    Great idea, a few comments about listing new revision:

    *New Revisions*
    [select all] [select none]
    [x] r41: #task_number1 - task description1 (add ">" option to see actual
    SQL below by expending it)
    [x] r45: #task_number2 - task description2

    In other words, I would add an option to see actual SQL below by expending
    it below.

    Also, I think we should auto-select all check-boxes since in 90% cases we
    do them all at ones (will save 1 click) either Synchronize or Deploy and
    rarely need to hand pick, but also can happen.

    DA

  5. good idea to add sql details, as well as having all checkboxes validated by default.

    Envoy

  6. With current layout I doubt we can fit all sqls there without extensive
    text wrapping.

    Also what about moving excessive description above synchronize/deploy
    buttons that Phil recommended to move to hints?

  7. Hi Alex,

    1. We can overcome wrapping with showing SQLs (for each revision)
    pre-formatted (as we do for Email body in Email logs) so it's easier to
    ready, but again it will be collapsed by default and you only expand it if
    needed.

    2. Yes, I think we can move Descriptions for both Deploy and Synchronize
    buttons into some sort of Hint element and have buttons sit next to each
    other so save some space.

    Please comment.

    DA

  8. I don't exactly understand how "some soft of Hint" looks like. Can you
    please rearrange elements on attached screenshot to make it look like we
    plan to see it after changes?

    Also I've noticed at least 3 errors in descriptions for Synchronize/Deploy
    buttons.

  9. Maybe we also need to display synchronized revisions the same way (but
    without SQLs) we display deployed revisions.

    Without it right now it's pretty hard to understand what happened after
    button was clicked.

  10. Without this right now I several times a day by mistake marked other developer revisions as synchronized and then spent additional time to figuring out why revision is executed in db, while in fact it was only synchronized.

    // CC: Dmitry Andrejev [Intechnic]