I have a SPA that uses breeze on the client, and also using the .Net wepapi2/EF6 server libraries. My current version for the client library is :
version:"1.4.6"
metadataVersion:"1.0.5"
The server DLL's have varying version #'s but were installed with the client lib at the same time, so pretty sure they're in sync.
I would like to upgrade the client version to 1.5.3 but not touch the server. Mainly because the server side is all compiled DLL's and if there's any code that breaks during the upgrade, it will be much harder to find/debug the DLL code compared to the client JS that I can see/debug/modify realtime.
So my question is, how coupled are the client/server versions? Can I keep my current server libs and upgrade the client only?
If I did decide to upgrade both, is there anything I should be aware of going from 1.4.6 to 1.5.3 in both the JS and .Net environments?
Thanks
Our recommendation is usually to upgrade both at the same time. In general, we very rarely have breaking changes on the server. ( None in recent memory). But we do occasionally on the client and these are called out in the release notes ( available on the website here: http://www.getbreezenow.com/documentation/release-notes.) Most of these breaking changes are pretty subtle and you are unlikely to ever see one, but...
What does happen occasionally is that we add a new feature to the client that requires some additional code on the server. But this would be unlikely to break anything unless you use the new client feature.
Hope this helps.
Related
I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
I'm trying to build a RESTful internal web server at work using node.js, where I'm currently restricted to using a Windows 2003 Server.
I've hit a stumbling block with regards to database support however. Are there any bindings currently available for reading and writing to sqlite, PostgreSQL or MySQL on Windows based machines?
Mariano has mentioned Windows support in the future in these comments, but ideally I'd like to use something available just now as a proof of concept.
I'm author of mysql-native.
Both official (felixge node-mysql) and my driver has been successfully used under windows,
I'm using and developing it under linux/windows 50/50% time . Feel free to contact me if you have any questions
Have you tried mysql-native? It's native (mysql) which means there are no other dependencies, so should run on any platform node supports. Seems to be actively maintained also, and has some examples to show you how to use the library. Link: https://github.com/sidorares/nodejs-mysql-native
Let's consider the What is the best strategy for dealing with hot fixes? question from the Flyway FAQ section. In this question:
Application version 7 (and DB version 7) is deployed in production
Work starts on app version 8
DB version 8 is developed and deployed in the acceptance test environment
Bug is identified in production
DB version 7.1 is developed and must be acceptance-tested
When flyway:migrate will be invoked against the acceptance test environment, it will notice that v8 has already been executed and so that there is no need to execute v7.1.
On one side it makes sense since v7.1 might not be compatible with v8, and it is not up to Flyway to analyze this. Fail-fast is entirely understandable.
On the other side, the only way to deploy v7.1 to the acceptance test environment is to clean the database and run flyway:migrate with target = v7.1, thereby discarding data that might have had its use.
Is there a feature I'm not aware of that handles this case or is clean + migrate.target=v7.1 the only option?
More than a different feature, it's about a different process.
If you do wish to keep your data in your acceptance environment, I would recommend shipping v8 of the database with the hotfix and the actual change can then be v8.1. The features of the v8 schema might remain unused until the corresponding code gets deployed. In most cases however, this causes no harm.
I'll admit up front my experience with Silverlight is minimal.
I'm working on a SL app that also supports shipping custom screens in the form of a custom DLL. I made a change to said DLL and it's gone through build and deployment to a QA box for internal testing. When one points IE to the app, for three of us the updated version of the custom screen is coming up, but for a fourth person the older version of the DLL is somehow being referenced.
We've done some usual suspects (closed sessions, cleared his browser's cache, even installed Firefox) but he's still referencing the older version of the DLL. We have verified that the DLL on the server we're all hitting is the newer version (but that's no surprise since the rest of us are getting it).
There seems to be something specific to the client machine (or maybe that guy himself is just unlucky). Where would you look next?
First step is to install fiddler on the "fourth" persons machine. Examine the request to server for the new dll.
Since I've not done this before I am not sure if the way I am planning to do this is okay or is there a better way. Like using Windows Installer or Install Shield or Windows Installer XML (WiX) toolset. Any help would be great, as I have no clue.
We have a product and we ship new version every few months. So far we've only been rolling out complete versions i.e. Either Version 1.0, or Version 1.5, but no upgrade from 1.0 to 1.2 to 1.3 to .... you get the picture, right! So any customer that get version 1.0 cannot upgrade to version 1.2 or 1.3 or even the latest. They'll have to uninstall old version and install the latest version. This is not right, but thats what we could do until now. But we'd like to change it.
My plan is to have a install file with (Sql Scripts) for each upgrade path. Check the table in database that stores the version info and depending on it run different script to upgrade database.
My concern is that this method may not be scalable, once we have more than 5 or 6 different versions.
If you could point to any articles or books on this topic, that would help a lot too.
Also, could we use Windows Installer or Install Shield for this?
thanks,
_UB
We've been using DBGhost for a year or so now to keep our database under source control along with our codebase, and it makes this kind of thing dead easy. It's not just well thought through, but they've been using it to roll out their own code for years, so it's dead solid.
Your problem is a pretty common one, and I've had to deal with this kind of problem at my last job. There is another tool aside from the RedGate tool that may help you do what you need to do. It's a tool called DB Ghost. They explicitly address the versioning problem, and have a packager as well. I would suggest doing a trial of the DB Ghost product because they have some interesting claims concerning multiple version upgrades. This was taken from their FAQ (http://www.innovartis.co.uk/faqs/faqs.aspx):
Q: Our problem is going to be managing
data structure changes during
upgrades. Our product line is
Shrink-Wrapped, or downloadable from
the website. So when a user downloads
an upgrade, they can be upgrading from
a very recent version, with few
database structure changes, or the
upgrade may be from a very old version
with a multitude of structural
changes. One upgrade needs to manage
it all. The user would be offsite, so
we can't hold their hand. We have
users in Greece, Australia, Malaysia,
Norway, etc. How would DB Ghost, if at
all, handle updates in remote
locations?
A: The DB Ghost Packager Plus product was
design to specifically address this
issue as it can dynamically handle the
required updates to a target database
seamlessly.
I'm just mentioning this because our company is trying to do something similar and I was doing research on this tool.
Thanks,
Eric
Do you insist on doing it yourself, or could you see yourself committing and investing in a tool?
I really like the idea of Red-Gate's SQL Packager, which will "diff" your two database versions, and then create a SQL script, a C# project, or a stand-alone executable to upgrade from version 1 to version 2.
Not 100% how you'd be able to upgrade from 1.0, 1.1, 1.2, 1.3 all to 2.0 - check out their website and see if they offer something for that scenario!
Otherwise, I guess it'll get quite thorny and messy......
Marc
In the Rails world they are using a tool/method called Migrations.
Basically is boils down to creating a small sql script to upgrade and downgrade each little change to the database.
When you are testing the application you migrate your database to the version you want and on deployment the application can check what version it needs and migrate to that version.
There are free migration toolkits for most popular languages, they might be part of some MVC framework though.
A nice side effect of migrations is that you have database source code that is easily stored in you source control repository.