I see that some people are updating their apps to Rails 3.1. When is the best time to update a production app? As soon as it is released? When the next stable version is released? A major release like Rails 4?
Currently running 3.07 app on Heroku.
Thanks.
EDIT: Yes, running Ruby 1.92p180.
Tests definitely.
The answer also depends on a lot of other factors about your setup such as:
What is your current testing stratgey? Do you volume test?
Do you have a lot of users that would drown your ability to respond if there's an issue?
Do you have a failover / fallback strategy/plan if issues arise?
What is your backup stratgey and how well do you execute it?
How complex is your code and how much custom code is there?
How similar are your development / test / production environments?
Is there a particular business reason to upgrade now rather than wait a month or two (given that it was just released).
Are you running ruby 1.9.2 (almost certainly but has to be checked).
Have you planned for staff availability for the downtime/interruption "in case"
Have you tested the actual planned move process on test servers to make sure there are no gotchas?
Generally I would wait 2-3 months. Especially so with Rails 3.1 as there were quite a few changes with this 'dot' release, although again tests should help - though that'll depend on their availability and completeness.
When all your tests pass.
I normally wait til at least the .1 release to update an existing production app. But i have apps runnig on 3.1 as they where developed using the betas and RCs, and so far no issues.
But seriously when all your tests pass.
Related
Why akka.persistence is still having beta release on nuget packages. Does it imply it is still not stable and not good for used in production applications?
In Akka.NET in order to get out of prerelease, a package must meet multiple criteria, like:
Having full test suite up and running. In case of clustered plugins, this also includes multi-node tests.
Having a fixed API. There are dedicated API Approval tests ensuring, that no public API has been accidentally changed.
Having a battery of performance tests. While many of plugins are ready and usually fast without it, stress tests are needed in order to check if any of the merged pull requests didn't introduce any performance penalties.
Having all documentation writen and published.
While this is a lot, not all of these are necessary to make plugin functional. In case of Akka.Persistence there are minor changes (like deprecation of PersistentView in favor of persistence queries), but the plugin itself is production ready and used as such already. However maturity of persistent backend plugins, that are used underneat, may vary.
Akka.Persistence is stable now. You can download it by running following command in Package Manager Console
Install-Package Akka.Persistence
I feel like I'm experiencing a common problem, but I wasn't able to find anyone asking about it.
As the title indicates, we're forced to use AccuRev for SCM. We have our development stream under our QA stream. Let's say we're working on a big project that will be in QA for weeks before being released (we're following a scrum strategy). In the meantime, there's a bug fix that needs to go out before this big project. The problem is the bug fix affects some of the same files the big project uses. How would I get my files from development to production, without bringing the big project with me?
Sorry, I hope that makes sense!
Thanks!
If you are using the change package feature in AccuRev, you can select that issue and just promote those changes into the production stream.
Otherwise, you will need to determine the promote transaction(s) of the of the bug you fixed in development and change palette those fixes into production.
I think I found a solution that will work for us.
I plan on creating a snapshot off of the development stream after each successful deployment to production. Bug fixes/smaller projects will work off of this snapshot. That way I can keep anything I'm currently working on in DEV from getting inherited into my bug fix. When I'm ready to deploy my bug fix, I'll create another snapshot and re-parent my big project there. Then I'll revert the change package in QA and development, re-parent my bug fix to development, and promote as normal.
It's a slightly modified version of what's explained in this article: https://accurev.wordpress.com/2008/03/27/pattern-for-stable-development/
what is the best when it come to choosing what version of rails to use in your development?
I wanted to upgrade to the newest version for the new features, but in many cases chances were high that my existing code would be broken, and a lot of extra time definitely needed to spend fixing it. Should I stick with the current version of rails I'm using? or heading for upgrade?
Any advice or guideline would be really appreciated.
It is useful to always upgrade, because new gems might not support older versions of Rails and you wil get new features from Rails which could reduce code. You can do it step by step, fixing time to time code that will break in newer version of Rails. It more like continuous refactoring.
I think you have to check carefully when and how to upgrade. Here are some hints that may help in the upgrade process:
Patch versions (like upgrade from Rails 3.1.0 to Rails 3.1.1) were normally no problem at all. Upgrade whenever possible, normally you don't have to change anything. Sometimes you have to check if other Gems as well should be upgraded, read the release notes, they give (sometimes) hints about that.
Minor versions (like upgrade from Rails 3.0.9 to Rails 3.1.0) come with new features and non-compatible changes. In the release notes, you will find information what has changed and has to be proven before hand. As an example, look at Ryan Bates railscast "Upgrading to Rails 3.1.0". You normally have to do the following steps:
Upgrade to the last patch version before.
Look at the deprecated log messages. These are the ones that may break after the upgrade.
Tag your current application, or branch to be sure to not destroy anything by the upgrade.
Do the upgrade up to the point you are sure most needed features work again.
Merge back your changes, and continue with the upgrade
(Have done that the last few days for an application I have upgrade from Rails 1.2 to 2.0 up to 2.3.8 to 3.0.0 up to 3.0.9, and now 3.1.1.)
Major version upgrades are even more difficult. You have to ensure that you have enough time and resources to check all the minor glitches you may have. Most of the time, there were resources available by the Rails team that help do the upgrade, like the Rails upgrade helper or the 3 railscast "Upgrading to Rails 3".
In any case, you should at least check if the main Gems you are using (additional to the normal Rails gems) are compatible with the version you want to migrate to. This may be tricky, but sometimes, the information is available.
My experience is, that Major upgrades take time, and if you don't have it, don't do the upgrade. Minor upgrades take some time, and depending on the change (assets in Rails 3.1) come with a price tag, which is sometimes, not all of the times, worth it. Patch upgrades are painless and should be done at will.
I have upgraded my app to Rails 3.1.0, and while I have solved many compatibility issues, but I have also noticed that there are many redundant files, junk codes, and some features I have to recode again.
I am just wondering if I should just rewrite my app from fresh in Rails 3.1.0, or continue modifying and fixing after the upgrade? The former one will produce a cleaner app, but more work, and the latter one will be faster, but will also take some time to clean up the mess. What is my best approach?
Thanks.
what I do is create a fresh empty rails 3.1 app. Install my gems with bundler. Then I copy over my migrations, my models and my spec tests. Run my tests. Get tests passing, resolve any incompatibility issues. Repeat with config/routes, controllers, views, etc.
Are there any differences between the original CruiseControl and the .NET port? I've compared the 2, but can't find any big differences except the language it has been developed in. I want to use either one of them for (automated) testing of web applications, using Selenium and Subversion, perhaps even Groovy but don't know which to choose.
[edit]
After looking at CC and Hudson, I've chosen Hudson for it's simplicity, it already has plugins to run Groovy scripts and Selenium as well
Choose me, choose me! (I work on the original CruiseControl.)
I've never used CC.NET but from what I know I agree that they are pretty comparable. Probably the most important difference is cross-platform vs. Windows only.
Now I wonder how long until someone comes by and says their both crap and you should try Hudson? ;)
(And of course there are lots of other choices...)
CruiseControl.NET (cc.net henceforth) has build queues (http://confluence.public.thoughtworks.org/display/CCNET/Project+Configuration+Block), which allows you to serialize builds that depends on a certain build order. I'm in the process of emulating this behavior in the java version of cruisecontrol but the functionality doesn't map one to one. The reason however, that I'm at all moving from the .net to the java version is that the .net version core dumps with mono (cc.net nightly build and mono nightly build as of two months ago). The fault lies with monos thread handling but voids attempts to get cc.net up and running.
The documentation on this can be tricky to find, if you don't notice the version numbers that the configuration examples/documentation adhere to (confluence.public.thoughtworks.org has the updated configuration documentation whereas ccnet.sourceforge.net has not. I know that the ccnet is most likely a dead site, but if your're not carefully reading the datestamps on every page you're visiting, this may bite you).
Furthermore, the sourcecontrol blocks for cvs and svn in cc.net are more granular and featurerich than their counterpart in the java version, but this has not been a problem in my work. The java version is also easy to extend/modify re: plugin behavior, but you would really just like to see this kind of work going upstream instead of forking.
I'm fairly impressed with both the java version and the fork in .net (modulo mono runtime behavior), but you really do not want to try any of the other forks of cruisecontrol. I've had peripheral experience with hudson, and the features were just not compelling enough to veer me from cruisecontrol. Hudson has a (somewhat coloured) comparison map of Hudson and CruiseControl (java) at http://hudson.gotdns.com/wiki/display/HUDSON/Home
A viable alternative is the python implemented buildbot (http://buildbot.net/trac). It does not have fancy gui dashboards and the setup is somewhat more commandline-bound, but if you're doing distributed builds, it's very easy to set up and get running.
I think for you it will come down to operating system, original can run on nix, and .net version runs on windows.
There are other automated build utilities that can do this as well, such as TeamCity in the windows space, and cruisecontrol.rb in the ruby world.
Also there is a PowerShell based build utility called pSake that can poll subversion and perform tasks.