best practice to publish new version of the project

Scriptcase 8 Discussion
#1

scriptcasers,

what you do when upgrading project version that is already in production?
assuming many new applications were added to project in development
now we have 2 database, one in development and one in production which is already having logs and users and transaction data

is it practical to add many applications to development and also add the required new users groups and give all necessary permissions all in development, then just replace the table of mysql with the production version database?

or it is better to upload the new applications to production then do all the necessary groups direct on production along with necessary permissions all directly on production?

basically for discussion to what you guys are doing when having production version running and meanwhile you have a new version in your development that you want to publish, that involves many new applications, users groups and permissions for each application

what could be best practice?

#2

It depends. If there’s a new sc version then I always upload the _lib, otherwise only the php files. If there are database changes then it depends again. Useually I just upload into a new version directory then test and if ok I swich old prod to new prod by renaming the directories.

#3

thanks albert
can you give me small hint what will be best practice for the scenario I mentioned above please
can i add the changed in db of development then replace the tables only? assuming using mysql (groups/groups_apps/…all security module but not the users table) is it practicle to do this or you advise otherwise? or to re-change everhting on the production and set groups/permissions groups_apps db in production again?
thanks

#4

I am facing a similar situation and looking for guidance from more experienced Scriptcasers. But here’s my take, FWIW. I would replicate your entire production environment - applications, _lib and database from production to a new test environment. Then I would apply your changes to the test environment as Albert suggested - applications, _lib (if appropriate) and I would use ALTER TABLE (assuming MySQL) to make your database changes to the test environment. When all is working as you expect in test, I would make a full backup of your production environment (obviously, but always worth stating) and apply the successful process you developed in the test environment to production.

I also have a question about how developers (who have an application in production) manage the process of new SC releases - both development and production environment. If you upgrade to a new development environment, the same production code might result in different generated applications. Also, if you upgrade the production libraries (or didn’t), perhaps that would impact deployment. Seems as if you need multiple Scriptcase environments at all times - one matching your production environment for each application in production and one for current development. So, if you you have 3 applications in production, you could need 3 separate Scriptcase installations in your development machine + 1 for current development (assuming you deployed at different releases of SC). How does one do this within proper licensing? (I do know you can request a license change, but I was under the impression that this was a courtesy for issues, and should not be a frequent occurrence). Good advise would be welcomed.

#5

hi bradk, correct me if I’m wrong please, you have more than one point and not directly related to new project version?
1- development/production that is correct , from dev to prod you can run that exercise when required, make sure it works in production as it is working fine in development, that is good practice, but you don’t need it all the time, only first time when you deploy to production, make sure all is fine, after that, you can just add new applications to your prod, leave _lib as is, no need to change it, unless you have new theme, CSS folder, lagnguage changes, new images in /img…etc so what i do is to always first deploy to localhost and adjust/tweak whatever required then upload that outcome to production… firs applications, then database changes, then add imgs and langauge/replace existing…etc. when upgrading the project

2- sc new releases doesn’t affect the production AFAIK, only development, you can safely update your version on your PC/mac and continue development… new generated applications will go to production finally and they must work… unless there is in the production library something needs to be added!? _lib

for me, i don’t always upload _lib like Albert, even when SC has new versions, still didn’t face issues in this regards, but keeping this note in mind so i may need to update the _lib too.

#6

You can deploy without marking “Lib enviroment” but it’s a good practice to copy _lib folder too (because it includes possible related files there), but it’s not mandatory. When you don’t check “include lib enviroment”, a _lib folder is generated anyway, with some css and so on.

About update prod enviroment, is not needed unless “major version” (8 to 8.1, 8 to 9 or something like this) or specified in changelog. For example, look into 8.1.005 patch:

Added option to increment the file name for existing files with the same name for fields Document (File Name) and Image (File Name) datatypes.
(Need to update production environment!)
#7

@MikeDE - I understand your point about adding new applications. Often that requires (in my case) changing a common menu application, adding new applications to the security tables, which creates more deployment risk and the need perhaps to test more before releasing. That said, I find that when I deploy even a single application, with no library updates, SC creates new files in _lib. I am not sure why. It also creates a new index.php in the project root. So, there are mysteries (at least to me) about why all this unexpected stuff happens, which leads me to be more conservative about development system updates and _lib updates.

@Giu - After being burned doing an incremental update to SC dev, I tend to download a complete version (_lib) included and reinstalling the software in parallel. At this point, I am probably a couple of revisions behind (034 vs. 039). I just don’t feel confident in my abilities to sort out the release details and understand when I must, when I should and when it’s optional to update _lib. The must is when SC says so (the example you provided), but I don’t understand why other _lib updates should or shouldn’t be made. What are the reasons (if not bugs) why _lib is updated?

#8

Well, in the _libs are also open source libraries like pdf stuff and others. Those libraries get new versions too. In general Scriptcase does not tell these kind of changes and perhaps they don’t update often. But I always do upload it to be sure that I’m uptodate whenever SC has released a new version.
Before installing a new SC version I always make a full binary backup so I’ll be able to revert if necessary.
When you have just updates in your application and you deploy without _lib, then there still is a _lib around to upload. It will not contain all the libraries but other stuff that’s needed, like images you have used, themes (and probabely language files).
I always deploy first to a local wamp situation to test my application before moving to production. It takes more time, but it’s the safest way.
In the university environment we have a full DTAP situation where we develop, test, enduser acceptance and production…

#9

Albert-

In your full DTAP environment, how do you manage SC licensing where your production environment may have been produced on SC version 8.1.034 and your development environment is on SC version 8.1.039?

#10

I don’t have a complex deployment scenario, but I don’t understand why you need more .icenses. One for development and others steps are tested with deployed app, not with SC itself

#11

If you develop (and deploy) an application at SC 8.1.034 (for example), make no code changes to your application, and then move to SC 8.1.040, you should test your project to make sure nothing has broken due to the SC updates. But if you have migrated your license to 040, you no longer have the ability to test changes or make repairs using 034.