Production vs development

[bob9145]

Looking for suggestions for the best way of running the same web project simultaneously one copy for ongoing development, while serving up the working copy that is in use.
Allowing me to move components, and other files from one to the other after adequate testing.

A parallel copy running at the same time. I also would want a parallel database so I can test the development copy without polluting the primary database.

Right now I am revising, or adding components to the project in use. It is not heavily used so this works, but is a hassle, and as my app grows in complexity, and I add more users this seems like a crude, and risky way to operate.

Bob

[Steve Wood]

Re: Production vs development

For smaller apps, or ones that I own and enjoy a little risk, I use the simple method of publishing directly to the app and fixing directly in the live app if necessary.

But absolutely anything critical or for a live client, you need a Dev and Production environment. The easiest method is to run both Dev and Prod on the same computer with your Dev environment running on a separate instance of Alpha, published to a different folder of course. You then publish changes to your Dev copy, test and then just move the individual files from Dev to Prod (e.g., you do not publish from Alpha directly to Production). This takes some knowledge of what files are necessary to copy from Dev to Prod. For instance, if you changed page or component security, you need to move the appropriate file to update that in Prod as well.

One of those files you need to understand is the a5_application.a5i file. It contains configuration settings for the website. You typically would NOT want to copy that from Dev to Prod as configuration on each side might be different. Typically what is different is the database connection string.

In parallel to this, I am taking a daily back up of my published Production files so that I can recover immediately if something does not work properly.

On the database side, I love using Navicat because it has a very easy "database sync" process that lets me quickly compare my Dev database copy to my Prod copy and update as required.

On larger accounts we have three separate machines: Development, Test and Production. I test on Development, the client tests on Test, and then I copy appropriate files to Production, and it is tested again. The Prod in thsi case is totally isolated on the network for security reasons and so getting updated files from Test to Prod is a little more difficult.

[GGandhi]

Re: Production vs development

I wouldn't use same app for development and production. to me it is messy and will get messed up in time.
I would use two separate apps one for development one for production whether they are in the same computer or not.
when you develop the components and test them and then publish to the production when happy. as far as db is concerned it is the opposite of what you do with app. you update the development from the production. just like steve I use navicat and dump my MySQL files and execute them in the development app.

for components, development is current
for db, production is current
the direction of update is important.

I just publish the whole folder over and over again. over time the files will be less and less. since I only work on small samples.

[bob9145]

Re: Production vs development

Thanks Steve good insight.
I'll try the second instance, and take a look at Navicate.

[Steve Wood]

Re: Production vs development

For clarity - I don't use the dump app, then restore. I use the streamlined Structure Synchronization.

And everything else you said, I would never do it that way for a critical app. There should only be one master copy of the app, you must fully test in a separate Test environment, and then copy, not publish, updates from Test to Production. (Or from Dev to Production if you do not have that middle Test machine.) The reason you should not publish from Dev directly to Production is because Dev is often a couple steps ahead of what you want to go live with. If you publish from Dev to Production it is likely to publish objects that are in draft mode and not ready for use. Unless you know how to control what Alpha will publish, it will publish objects you do not want published. But again, on smaller less critical apps with no real Release/Build protocol, just publish direct to Production as you say.

[CharlesParker]

Re: Production vs development

I develop locally and test locally then publish live. I usually test on my production server as well using a filter so that ONLY I see the test component, then once I am satisfied remove the filter. So far so good and Alpha has come to the rescue with auto backups every time! The only thing you really need to watch is when working with sql - if you leave off a where clause you can devastate a table, #learningcurve.

[GGandhi]

Re: Production vs development

steve, it makes sense.

so far i develop and test locally and when happy i publish to the server, it is working without any problem. but your method of intermediary test server makes sense. i will try to implement that and see how it goes.
as far as mysql dump and restore, that is the easiest for me. since i work with more than two computers with that db and use dropbox to send and receive the sql file and restore works well. ( also i use navicat lite, free version)

thanks for sharing the information.

[Steve Wood]

Re: Production vs development

Gandi,

As soon as you get other people involved, typically a larger client, you need the intermediate layer. It also is a safeguard for the developer as the developer "should alone not test their own code" in mission critical applications. The triple layer "DEV / TEST / PRODuction" are more in line with an agile development process with build numbers, Release cycles, checks and balances.