Tools such as liquibase and flyway certainly make it easy to upgrade your database. What I haven't gotten straight in my mind is how to best handle changes that occur both on a release branch and trunk.
An example:
My code that is in product is version 2.5 and lives on a release branch. In the meantime, developers have started working on version 3.0 which lives on trunk.
A bug is found in production. A database change script is made (2.5.1) and committed to the release branch. The same change script must be merged back to trunk (3.0.1?).
Version 3.x is released into the wild production db's will already have the change from 2.5.1. The upgrade could potentially fail.
Conversely, if I'm creating a db from scratch if i was using a forward only strategy I would have the same change occurring twice (2.5.1 and 3.0.1).
How are others handling this scenario?
You are right to recognize that production DB changes will always be linear.
To solve this you should place DB migration 2.5.1 both on the branch and on trunk. And not create a 3.0.1 with the same changes!
This way it will be deployed with the branch, but also with trunk.
Upgrading production to trunk will then
find migration 2.5.1 and skip it, as it has already been applied
find migration 3.0 and apply it on the 2.5.1 db
There is, of course, an ever better solution. And that is to get rid of branches altogether and always release from trunk using to feature toggles instead.
Related
I have a npm package which is currently lets say version 1.2.2. I am just about to release version 2. I still want to be able to maintain version 1 alongside version 2 for bug fixes and so on. What would be the best approach to separate code of both versions. #latest will be stored on git master. Where would you store version 1 code? Separate branch, repo? How do people do it in the industry?
Where would you store version 1 code? Separate branch, repo?
Yes, you should maintain two or more branches.
Master branch could be currently working code so it can be either 2.0.0 version or 1.2.2, but since you haven't released version 2, master branch should contain 1.2.2.
And you can create 2.0.0-dev branch and work on it.
After you release version 2, you can merge 2.0.0-dev branch to master branch, and maintain 1.2.2 branch for LTS support and bug fixes.
Also, you can manage releases in github, if you're using it.
I'm maintaining some js library. Releases follow SemVer. Current stable version is 1.5.0. I'm working on 1.5.1 and have 1.5.1-beta.2 which is published at npm with "next" tag. Today I got bug report, discovered the issue and ready to fix it. The thing is that 1.5.1 is not going to be finished during nearest days, it turned out to be more complicated than I planned initially. But I want the fix to be published.
What is the right strategy in this situation? Obvious approach which I'd like to avoid is to postpone the bug fix until 1.5.1 is done and published and then release 1.5.2 containing the fix.
Another way is to publish the fix as 1.5.1 based on 1.5.0 and then continue previous work switching it from 1.5.1-beta.2 to 1.5.2 or even 1.6.0. I'm concerning about inconsistency with the result chain in this case:
1.5.0 → 1.5.1-beta → 1.5.1-beta.1 → 1.5.1-beta.2 → 1.5.1 (bug fix, based on 1.5.0) → 1.5.2 (based on 1.5.1-beta.2)
How such collisions are being addressed using SemVer?
Okay, so you have bug set A currently baking as 1.5.1-beta2 and you have a new bug set B that you want to get the fix out for immediately. The correct mechanism for this is to fork 1.5.0, fix bug set B, and release 1.5.2 (assuming you don't need a beta). Then merge your B fixes into your A working branch and release 1.5.3-beta1 and proceed to drive that to an official release.
It gets a little more complicated when you have two parallel beta sequences running, particularly when you're not sure which is going to make it to release first, but it is manageable. The key is to to just keep in mind, how SemVer precedence impacts the decisions your customers make (the algorithms they apply), whether to fast-track a particular version into their production systems, verses how their developers pull bits from you.
My production systems, have two inputs:
Development is the product of my engineers.
Automated maintenance is the product of a system that:
Pulls patch releases and applies them to a fork of my current production code.
Tests the applied changes against an extensive suite of functional and performance tests.
If the tests are green, flight tests the changes in my production environment, while monitoring for unusual changes in production failure rates.
As long as everything is going well and a human doesn't step-in to stop it, eventually rolls out the changes to the entire production system.
There are of course, variations for services and packaged products. The point is, you can use your release points to signal to your customers automation, or developers, that you have an important bug fix that has little risk of breaking anything. There is no requirement that 1.5.2 have any lineage back to 1.5.1-beta#. You are not required to ever release a 1.5.1. It is customary however to add a comment in your release notes that 1.5.2 is a hot fix for the bug in 1.5.0 and does not contain the fixes in 1.5.1-beta#.
While you may never encounter a need to do so, you don't have to include the bug fixes from 1.5.2 in your eventual 1.5.3 release, provided the later release, passes your quality controls. It is sometimes the case that a specific bug fix, winds up not being applicable in later releases.
How you maintain your product quality is entirely up to you. How you signal the level of risk/importance for a specific release, is defined by the SemVer standard.
I'm trying to upgrade a very old version of Aurelia CLI project v0.24.0 to the current version v1.2.3. I've tried to follow the steps from this link from the docs but when I try to run it I receive this error:
So my question is what is the best approach to upgrade it from such an old version to the newest one?
Just a screenshot of error is too little info to give proper advice on. And between the currently latest version of v1.2.3 and v0.24.0 (Jan, 2017) there's roughly 3 years. Fun part is, you'd be amazed at relatively how little Aurelia core itself has changed. Simply because a lot remained stable.
Most impactful changes will be in either:
aurelia_project folder, with the build and config routines
bundler config (system.js, webpack, requirejs - whichever you've used)
That being said, this does not necessarily mean that your dependencies have also remained stable in those past three years. Especially in Javascript world. To accommodate for this, I would suggest:
Create a blank, new project with the latest Aurelia CLI
Copy/paste over the /src folder from your old project to your new one
Take in consideration specifics, like package.json from your old project and migrate them by hand (reinstalling) in your new project
Again, try to keep your bundler similar and you will have relatively little changes. But if you choose you want to migrate from System.Js to Webpack, it'll be a bit more hassle. But arguably, rewarding in the end if your project needs to be kept alive for a longer while.
Considering the age of your old project, restarting with a clean setup and config is what I would consider to be "the best way" to retouch only the necessities.
I'd very much appreciate anyone sharing best-practices, patterns, anti-patterns, backup, rollback processes that you have formulated for a pain-free, foolproof, Play framework upgrade.
I'm thinking just replacing the bin/play directory with the latest version can cause problems
Edit:
I'm looking for more specific version management strategies, say,
a) Do you just have /bin/play directory having the latest play version or
b) Do you keep versions like /bin/play-1.1 /bin/play-1.2 and change your $PATH to point to the latest (cons: you have to rebuild your modules, dependencies & libs; pros: gives better control over rollback)
I prefer to install play from source using git:
git clone git://github.com/playframework/play.git
cd play
# checkout specific version
git checkout 1.2.1
cd framework
ant
cd ..
ln -s $PWD/play ~/bin
So I have a full install including all source. Later, when play was updated to version 1.2.2 I did the following:
cd <play_home>
git pull
git checkout 1.2.2
cd framework
ant
In your application you then do
play clean && play run
The advantage of running play from a source build is that you can always and easily roll back to the previous version or even test out features from current development. This does not solve the problem of having multiple versions of play active at the same time though.
I agree with Andre. However, if you are asking for best practice for a live project, I would do it differently.
You can have multiple version installed on your local machine. The only thing you have to change is which one is visible in the path. For instance you could have 1.1, 1.2, 2.0 and depending on which one you want, you just modify your /home/youruser/.bashrc file.
The reason, why simple update of play from git or hg will not work/good idea is because, incase there are problems, you have to revert, rollback modules, or goodness know what not.
It is far better to simple swap out the play version, rebuild, test extensively, once you are ok that everything is good, then you can make the same changes in a live site.
If things don't workout, or your are hopelessly lost, all you have to do is revert the changes to your project and switch the play version. You will be back to where you started.
Is there a good reason to continue deploying newer snapshots, if there's already a released artifact of the same version?
Concretely: There's already xyz-1.0
There's projects continuing to have xyz-1.0-SNAPSHOT dependencies.
It appears wrong to me, but maybe there is some reason behind this?
If 1.0 has already been released, the snapshot should not be built any longer and you should probably remove the snapshot from your repository. If new development starts, it should be on 1.1-SNAPSHOT (or 1.0.1-SNAPSHOT, however you decide to do your versioning).
The only time that a project should be deploying snapshots after a release version has been deployed is if it were an alpha, beta, milestone or release candidate.
As you have suggested the projects in question are doing things wrong. After the xyz-1.0 release the SNAPSHOT versions should be updated to the next development version, 1.0.1, 1.1, or 2.0.