I am currently working on a project, where we want to give long-term support (LTS) for some specific "LTS versions" which we will release in the future.
Like the name says, we want to give support (bug fixes/patches) for this LTS versions over a longer period of time, without forcing the customer to update to the newest version. Each customer has his own local database.
Now the problem is, what if a patch of a LTS version contains database migrations? Is there any good pattern/guideline/best practice how to handle this situation?
We use a migration-driven database delivery approach similar to what is described here: https://enterprisecraftsmanship.com/2015/08/18/state-vs-migration-driven-database-delivery/
Example
The first LTS version "v1" with migration "M1" has been released and install for customer "A".
The last recent release is "v2.3" with migration "M16"
Now a patchversion "v1.0.1" is necessary with a migration "X" (which f.e. changes the type of a column from int to bigint).
The problem
The customer has installed "v1.0.1" and now wants to update to a newer version.
One idea is, that he only can update to a version which contains migration "X", so that the code is compatible with the data base. But there is still following problem:
At the time when migration "M2" was written, migration "X" didn't exists. What if it (or some of the following migrations) is not compatible with the changes done by migration "X"?
Related
We're working on an application that is being used by multiple customers, each having a different version of the app.
Our team is currently following the Git Flow branching strategy, but we've been hitting a wall on maintaining a single master branch.
For example:
Customer A has v1.1.2
Customer B has v1.1.4
We have fixed a vulnerability for Customer B in v1.1.4, and updated the version to v1.1.5 in the master branch.
Now Customer B has asked for the patch fix in their version, but does not wish to update to v1.1.4 as of yet.
This fix then gets versioned as v1.1.2.1 (still on its release branch).
We are currently maintaining multiple release branches and pulling in feature branches in as needed, but we feel this isn't scalable in the long-run.
Is there a recommended solution or branching strategy for this?
Maybe you should create release every x.x.x version also fix your bugs on x.x.x.x versions and your customers can use this versions.
So there can be many x.x.x version. You can think this x.x.x versions are kinda major.
Did you tried looking for oneflow approach where you create the new branch from previous release.
Try having a look in this https://www.endoflineblog.com/gitflow-considered-harmful
There are two main updates - new features and security updates. The new features can be maintained per customer as per the version numbers. However, the security updates can be given as a patch that is available from v1.x.x onwards. This would decouple the vulnerability fixes and the feature updates. You could put the patches in a specific branch and someone could merge their given branch with the latest on the security patches branch.
You could send an email everytime there are new security patches.
My suggestion is to move your Softwares components to multiple seperate repositories.
You can then include them as subrepositories in different states in the different branches/repositories (you would have tp create a branch or repo for each customer).
We use liquibase to generate database changes but need these scripted into SQL files because our DB server has neither Liquibase nor even a JVM installed.
We use the updateSQL command to create the DDL script needed to make changes, however if we run (on our development server) a 'dropAll' first we get a change set for every release.
Is there a way to run Liquibase regular 'update' for one collection of changesets (i.e. all prior releases) and then produce updateSQL output only for the last release? Essentially can we parameterize our build process to indicate the release we are targeting and automatically produce only SQL for that release?
Thanks
We have a similar setup.
The way we handle this is we have an "integration" db that always keeps the last official release.
When we have a new release candidate we let liquibase run (updateSQL) against that integration DB. Since it is on the last (resp. the current) release, updateSQL will only write out the difference between the new release candidate and the last release.
So you have a delta ddl that needs to be applied to go from release x to y.
Once the release candidate is released we let liquibase also update the integration db.
There are several ways to run a portion of your changelog.
If you break up your changelog files using versions (changelog-1.0.xml, changelog-1.1.xml, changelog-2.0.xml) and then have a master changelog.xml that <include>'s them, then the easiest solution for you may be to just run updateSql passing in the changelog version you want. If you want to generate sql for the entire database, run "liquibase --changelogFile=master.changelog.xml updateSql". If you want to generate sql for just version 2.1, run "liquibase --changeLogFile=changelog-2.1.xml updateSql"
#Jens answer works well and is what I often suggest. It has the advantage compared to the above option of catching new changeSets that were introduced into old changelog versions through a merged in patch release, for example.
Beyond that, you could use context or preconditions to dynamically control what is ran. Depending on your setup there may be ways to get those to work well for you.
Finally, there is always the extension system where you can write custom logic around how changelogs are parsed and executed to pull out older version changeSets based on file name or some other mechanism that works for you.
Hello,
I am new in NopCommerce. I have change in Nop.Core, Nop.Data and Nop.Services. I have change also in some controller, Model and view of Nop.web.
If i wish to upgrade nopcommerce version from 2.8 to 3.10 then, which way is easy and best.
1) I backup my file and get update. Once update is finished then, may i replace only those part which i have updated and differ from original code? May i add new method which is in my backup file but not in original code?
2) Or May i have to create new plugin or other way.
[For example: I have change in product table and add new fields like size, age, color.]
Please let me know your valuable feedback.
Thanks
There is no straight right or wrong answer. I am suggesting on the approach i took. Assuming you have code changes and database changes on top of base nop 2.80.
Ground Work
Write down a detailed modifications list. (Additional functions you have added on top of 2.80.)
Check with 3.10 if any of your modification is supported out of the box.
My modification count was 250 (very detailed up to estimation).
Approach
Upgrade 2.80 db to 3.10 db.
Modify 3.10 code to support new features of 2.80.
DB Upgrade
Find a good database diff tool. ex: SQL Compare.
Restore your production (2.80) DB to your dev pc and install nop 3.10 db into your dev pc as well.
Compare both DB table by table. Basically, you are going to upgrade 2.80 db to 3.10 db by comparing 3.10 schema.
Alter/Delete/Add new columns in 2.80 by comparing 3.10.
Create Store information (Store table). This is new feature in 3.10 and StoreID is needed for most other tables.
Update customer data to match 3.10 schema.
Update products information. ProductVariant table is now merged with Product table. So need to update product table.
Update Order details. OrderVariant is now OrderItem. So move the data.
Move other tables.
I used to create single SQL Script which,
Restores Production DB from a backup file.
Script block for each table which, upgrades each tables and populates data.
This gives you flexibility of run and run and again run the script if there is any error or even this is helpful during scripting.
In addition to this, if you are merging 2 or more stores in to one,
Add all store information in step 5.
Now create a separate script for each store from this point.
You need to find different sequence number for OrderId & Customer id. Can't be same.
When you add 2nd or more store, check for existing customer before adding.
Check 01
Now take a fresh 3.10 code base and run against your migrated db. All should work well if you have done migration properly.
Code Upgrade
There is significant changes to be done on code simple because there is noProductVariant table. So all the custom logic needs to be re written.
Main issue is, invoicing. If you have more than one store, there is no email setting per store basis. So have to custom modify that too.
A good approach would be,
Do all the customer side eCommerce fist.
Then do the admin side.
If customer and admin in same functionality, do together. example, custom modification on order placing work flow.
There will not be big modification needed for plugins.
Check 02
Run the migrated DB with Updated 3.10 code base. All should work.
On Big Day
Backup Production DB and Production Code base.
Run the Upgrade scripts and Replace new code base.
No 3rd Step, since you have done all the hard work before this.
Ok, if you screw up, then roll back.
Things to Note
I learned these by testing. thank god, i found them before actual migration.
There is no detailed instructions at the time we were migrating on how to setup a complete multi-store solution in nop commerce side. There is a instruction here on how to setup nop commerce in production server. but i is not covering all the aspects.
We were using VPS Server to host our platform. If you are using VPS, please beware that SNI is need to be used if you set up multi-store properly. Only IIS 8 and above supports SNI. Which means you need Windows 2012 Server. See here and here for more on SNI
We were using Pleask to manage the server. So set up master domain as primary and all other stores as alias. In IIS side, RDP in to VPS and Set up SSL for each domain using SNI feature of IIS8
Down side of SNI, it is not supported by all old browsers. See here.
Limitations
If you are using Pleask, then email wont work very well. Since email box will be created only for master domains and all other alias will share the same email accounts. So you can send a reply from alias email. unfortunately, its out of nop commerce development scope.
i haven't found a solution for this. working on this.
I'd recommend doing the database incrementally. According to the upgrade guide, you must apply the upgrade scripts one at a time, just read through the guide and have at it.
I want to add new field "deadline" for tickets in a Trac system .
How can I do it?
take a look at Custom Ticket Fields.
I'm working with a modified revision of the Trac development version 0.13dev, that has support for true custom time fields. This version performs well in production for more than a year now, but still lacks some requirements like unittest to make it's way into the next stable release of Trac. Until this is at least in 'trunk' you'll have to take a special revision from the repository, patch Trac code on your own or use the DateFieldPlugin.
BTW, there is CustomFieldAdminPlugin to help you prepare properly formatted entries for [ticket-custom] section of your trac.ini .
I would like to get an automated changelog from Trac, that will include references to tickets that made some important changes to the architecture/design of the code. My ideal scenario would look like this:
According to some ticket I make a change to SVN
I add some specific line to the ticket saying that this changeset created an important change to the code/wiki
I go to some dedicated Trac page and see a full list of such changes made with the project.
In other words, it's going to be a changelog, which is available for all project participants, and the entire team will be updated about the important changes with source code and wiki.
Can you suggest any Trac plugin for this? Or maybe Trac itself can do it?
ps. Would be excellent to have another "Plans Log", where everybody can post their plans on future changes. Again, inside tickets.
Have you tried the ChangeLogMacro on TrackHacks: http://trac-hacks.org/wiki/ChangeLogMacro
Sample:
[7280] by doki_pen on 12/18/09 20:27:15
Update body reference to output.
Since body isn't defined. Fixes #5538
[7191] by doki_pen on 11/26/09
02:18:32
watch user feature
fixes #3546
[7190] by doki_pen on 11/26/09
02:18:21
copy changes
trying to make things more intuitive
for users
Personally I'm looking for something a little more like the VirtualBox changelog which I can then put into a plain text file. So if anyone knows how to do this I'm interested!
www.virtualbox.org/wiki/Changelog
Sample:
VirtualBox 3.1.2 (released 2009-12-17)
This is a maintenance release. The following items were fixed and/or added:
VMM: fixed SMP stability regression
USB: fixed USB related host crashes on 64 bits Windows hosts (#5237)
Main: wrong default HWVirtExExclusive value for new VMs (bug #5664)
Main: DVD passthrough setting was lost (bug #5681)
VBoxManage: iSCSI disks do not support adding a comment (bug #4460)
VBoxManage: added missing --cpus and --memory options to OVF --import
VirtualBox 3.1.0 (released 2009-11-30)
This version is a major update. The following major new features were added:
* Teleportation (aka live migration); migrate a live VM session from one host to another (see the manual for more information)
* ...