Further Improment on Project Deployment Processes

[Dmitry A.]

Hi everyone!

We have added a nice and really useful feature in our 5.1.3 release allow us to more streamline the deployment processes for Database changes to DEV and LIVE sites. It's fully described here Improving Project Deployment Processes to DEV or LIVE servers .

I am thinking we can take it a little bit further and add the ability to output/show the actually comments or notes whatever we call them from "project_upgrades.sql" file after Deploy button was hit in the Admin or OnDeploy script was ran via "do_update" script.

The main goal of this change is to show the developer which Revision has been executed + see any of Additional Notes supplied by developers. The output can be shown right below the Toolbar buttons and can look something like this:

============ 

# r2: Separate CMS Blocks for Logged-in / Non-Logged in (#34344)

# make existing content blocks for non logged-in users only

# create logged-in version of content blocks from their non logged-in version

# r3: User Attachments (#34351)

# r4: Admin of Portals (#34354)

============

Also, it would be nice to show OK or FAILED next to each Revision and may be show failed SQL so it's easier to catch those cases when something went wrong and you need to know where exactly it stopped. 

Please give me your opinion on this idea.

DA

[Alexander Obuhovich]

Here is the plan of implementation:

1. don't remove all comments before executing sqls

2. during sql processing if we see, that it's a comment, then display it (whole version) and if sql replace \r\n with spaces and display first 80th symbols and [ok] near that sql - 0.3h

3. if error during sql processing then display sql in same format as normal sqls above but FAILED instead of OK and SQL error listead after failed (in red color) - 0.2h

4. display deploy output on "System Tools" page too (just don't do redirect) - 0.5h

5. show complete revision title (not only number) during it's procecssing - 0.5h

6. show revision title in bold (use escape sequences in command line and <stong> tags when in HTML) - 0.5h

---

2h

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Great implementation outline Alex!

Please create a task for this.

DA

[Alexander Obuhovich]

Here is the task: http://tracker.in-portal.org/view.php?id=1208 

[Alexander Obuhovich]

Done. Ready for testing.

[Dmitry A.]

Most awaiting task - can't wait to test :)

DA

[Dmitry A.]

As I know Alex has recently added there an ability to see (as output) "affected row count" after SQL has been executed - thanks Alex!

Would you please add "affected row count" to the LOG file - this is great to have it saved for the future reference (you never know when it might be needed) ;)

DA.

[Alexander Obuhovich]

Done.

[Phil]

I didn't have the chance to test it yet, but it seems to be a real improvement, which should be told about into main in-portal features, isn't it?

This project-oriented tool is the only one I know in integrated environment (framework+cms+e-commerce)... I don't know for Magento, but I'm sure that other's CMS don't have such feature, aimed to bigger projects.

Envoyé avec Sparrow

Pièces jointes :

- deployment_script_display_affected_row_count_log.patch

[Alexander Obuhovich]

While testing this all improvements on real projects I can in a need of performing PHP-based upgrades as well.

We could use same idea as for In-Portal upgrades:

1. create /modules/module_name/install/project_upgrades.php file
2. within a file create a kBase class descendant
3. if we have revisionN method (where N would be a revision number from project_upgrades.sql) then we run if before and after executing sqls

Sounds good, however unlike with In-Portal upgrades we don't place revisions in project_upgrades.sql file unless there are some sqls, that needs to be executed.

And we can't use revisions in php upgrade script if we don't have them in SQL, since during next upgrade somebody could create sql revision that would match already executed php revision.

Any ideas?

[Phil]

don't the answer is in your question: store all revisions in SQL?

Envoyé avec Sparrow

[Alexander Obuhovich]

This would be obvious solution, but it's not as easy as it seems at first.

[Phil]

ok, then I'm out of the game here :)

Envoyé avec Sparrow

[Dmitry A.]

Hi guys,

Here are some of my ideas:

1. I don't believe we should use the same Revision numbers for SQL and PHP upgrades. Instead I propose have 2 and they can run their own numbers. I realized that SQLs are more independent which means usually they are used just for DB changes in structure and sometimes in content while PHP upgrades are more sophisticated (can easily do DB structure and content + custom content changes like images/files copy/delete/move) and should be allowed to be run on it's own.

This rises a couple of questions:

a. Who's (PHP or DB upgrades) will be running first during OnDeploy event? I believe PHP upgrades should be the one that have more control and can be run first. Possibly we want to trigger SQL ALTERS within themselves.

b. How do we track PHP upgrade? I say the same way we do with DB Revisions - store in DB - under the module in new column.

2. Another idea (not sure if good one) to use single upgrade functionality:

What if we make it more simple and just move to a single Upgrade structure when we have PHP upgrades controlling and doing SQL execution as needed - basically move things from SQL file into PHP and create new PHP method the same way we do with SQL upgrades file now. The idea is that we have much more control in PHP file and probably will not need to thing about BEFORE and AFTER scenarios at all.

What do you think?

DA

[Alexander Obuhovich]

Actually we've decided not to do this one because cases when there is a need to execute PHP code during deployment are very rare.

[Dmitry A.]

Agreed to put part with PHP code deployment on Pause for now.

DA