Testing the "Release Candidate"

[WendyWelton]

My A5 startup screen has been telling me for awhile that a Release Candidate is available, and it then very clearly says This is not an official patch, so you should not deploy this update to a production environment." So how have folks been doing this? Do you patch to test and then roll back? Do you install a second instance of A5? Can you even do that? And what happens with licensing etc when you do that?

[peteconway]

Re: Testing the "Release Candidate"

Whatever you do follow that advice do not use these Release Candidates in a live environment - if you have one licence then you have to bite the bullet to see if it's going to go off. The biggest issue is when you make edits and use features - then find it may not work, then your grids and dialogs may not work when you return to the previous version. It must be on its own. Take care.

[bea2701]

Re: Testing the "Release Candidate"

Pete is right, glad you are back on the forum and your willingness to help other developers is very valuable thanks.
Beta testing should be done in a non production environment, however, strange that no license exists for beta testers.
question as a developer with a small private company like Wendy, you buy more IDE LICS test in my opinion is wrong, it's about testing and not production.
like no other company I see "Selwyn R & D labs" able to serve customers efficiently, with this reason I chose Alpha V11.
Alpha Labs provides opportunity to test new software, which is great but not at the expense of all paid licenses.
feedback from A5 to developers' R & D "significant for the final quality of the product will benefit everyone.
pre-release candidates invest time / money into new functionality.
I hope in the future, an official beta program / partner arises with liability / discount for release candidates (NDA) would be correct.
The rest is up to Alphasoftware <R&D>, I think best is to wait for offical response by Sales/Marketing
M2P
Eric

[WendyWelton]

Re: Testing the &quot;Release Candidate&quot;

Thanks guys,

I actually wasn't trying to set off a firestorm or to get into a debate about beta testing in general. I really do just want some advice from folks who are testing it and also have to maintain a production environment. I'd like to test it, have stepped on my share of land-mines, and just want to do it the smart way.

[WendyWelton]

Re: Testing the &quot;Release Candidate&quot;

The biggest issue is when you make edits and use features - then find it may not work, then your grids and dialogs may not work when you return to the previous version. It must be on its own. Take care.

Now that there is valuable advice. I might not have known that. Thanks.

[WindForce]

Re: Testing the &quot;Release Candidate&quot;

Wendy
You can install A5V11 in your laptop for instance and do there all the testings etc...(i checked licensing issues about this with Alpha and they're ok with it, as long as the computers using it are not in the same network).
While starting to use A5 a few months back, i installed the main version which i use for dev and production on a privately hosted server, and also on my laptop where i installed betas, new versions etc...
Jaime

[WendyWelton]

Re: Testing the &quot;Release Candidate&quot;

Jaime,

Thanks - I had forgotten about the laptop!

I also got another suggestion via private email - you can install a second instance of the Developer module by specifying a different directory, like A5V11-2, the same way you would install a second instance of the WAS to do a staging site, like in this blog article - Why you should use a staging site for Alpha Five.... I'm going to try that in the morning. Since licensing for the Developer is per machine, as it is with the WAS, that shouldn't be an issue. I'll let you know how I make out!

Oh, and do that staging thing for that end of testing - as Peter has wisely pointed out, keep everything separate (edit your Profile to publish to the right web root...) The only thing the article doesn't say is how you view your testing site. In your browser address bar, you put your IP address, a colon, and the Port number - like the image below.

If you're using Always Up, they have a couple of good blog articles on how to do the second instance.

viewing_staging.png

[peteconway]

Re: Testing the &quot;Release Candidate&quot;

I stand corrected but you need to watch the second instance etc - my understanding is the install (patch) can make changes to the Windows registry, once that is done you cannot reverse them unless you know where it is. So even reinstalling the official patch can then cause problems to get things working again. Stick with a totally different PC.

[WendyWelton]

Re: Testing the &quot;Release Candidate&quot;

I stand corrected but you need to watch the second instance etc - my understanding is the install (patch) can make changes to the Windows registry, once that is done you cannot reverse them unless you know where it is. So even reinstalling the official patch can then cause problems to get things working again. Stick with a totally different PC.

Hmmmm - another good thing to watch out for. Thanks.

[JerryBrightbill]

Re: Testing the &quot;Release Candidate&quot;

The suggestion to install the release candidate in a separate folder is a sound one as we do that in testing all the time. While both instances will share the same registry settings, typically that should not cause any problems as most users use the same settings for both. The only "catch" occurs when applying a patch as the default install path will be the path of the last patch install, so it is important to know which instance is being updated and select the correct path for the instance being patched.

Almost all of the registry settings are unique to each user, so another way to segregate the settings is to set up another administrative user on the computer and install the release candidate under that user, or just install on a separate computer.

However, there are some very important caveats when using a release candidate build. A release candidate build may include features not supported in the release build. If you edit anything in the new build, it may not run under the release build. For example, a grid modified in the release candidate full build will run on that build, but may give an error if published to an Application server running a release build.

The release candidate build may only have slightly different support files such as JavaScript files. If you have tested a page or component build in the release candidate in a browser, you may need to clear the browser cache when running pages in the release build. Many of the JavaScript errors we see in Live Preview or published elements occur because of incorrect support files in the browser cache that have not been replaced.

You can usually roll back to an earlier build with no issues, but any changes made in a newer build may have to be re-saved in the older build. For that reason, it is a good idea to test the release candidate in a separate instance of a database.

As indicated in the prerelease notes, This is not an official patch, so you should not deploy this update to a production environment. The release candidate should ONLY be used for testing.

In any case, you should never publish anything built in one build to an application server running a different build. This will almost always cause problems.

[WendyWelton]

Re: Testing the &quot;Release Candidate&quot;

Thank you Jerry,

That tip about installing as a separate user sounds like an excellent way to go. Heck, even I know how to do that!

Would I be correct that using a staging site on the same hosted ISP server as the current build, there shouldn't be any issues or caveats (other than making sure you update the correct one, of course - the old "don't be an idiot" clause that applies to all of life)? They're completely separate if done correctly (I see separate session folders for each of mine...)?

[Editorial Mode ON]

For the record, I think it's excellent that you expose the work in progress to us like this.

I beta test extensively for another software company (different type of product altogether) and I've always found it leads me to understand the program better and that my feedback can lead to features or tweaks that are useful to me. People there periodically talk about beta testers getting discounts or some other compensation. The problem with that is, from my experience over a good 5 cycles, is that the quality of reports varies so wildly from tester to tester, and even cycle to cycle for the same tester, that it would simply result in people signing up to get the discount, without any good way to filter for quality. Picture any episode of Law & Order where some "helpful" citizen posts a reward for tips - they have to put on extra staff as the phone lines light up with 99.9% garbage. What I have found is that if I'm a very good tester - report everything I find and report in a way that's clean, clear and concise, the benefits are very real. Suddenly my suggestions and feedback are heard much more clearly. For me, getting a single feature from my wish list implemented, even a minor one, can be priceless. It's all about time. A single time saver in the program I use 60 hours a week, well that time adds up real fast. I don't think it's an official policy, just human nature - those being actual human beings on the decision making end, after all.

I also have had experiences with other software where something was released as "done", which in fact was still buggy as all get out. Autodesk is a huge company. I haven't use AutoCAD in years, so this may have changed, but way back when, we knew, we KNEW, not to use a new release for at least 6 months. It seemed to us that they'd release to hit the date, without regard to whether it was truly ready or not. It would be buggy buggy buggy, and the bug fixes were slow in coming - a deadly combination. Alpha Five's swift bug response is not the norm! I'd much much much rather be told honestly that it's still being worked on and given an avenue to see it and test it while still preserving my nice clean production environment - or even just get up to speed with the new features. So, thank you for that.

OK - that's my one and only two cents on that topic. As I said earlier, I'm not looking to get a long winded firestorm debate thing going. Having started this thread, and seeing a wee bit of angst perhaps, I thought wrapping it up with that other view might be good.

[Editorial Mode OFF]

[Humor mode ON]

Now I'm off to spend the day with Steve Workings, having just spent a good portion of the night with him. Relax Mrs. Workings! I'm talking about his videos. I'm evil. I was talking with the IADN roundtable group yesterday about how few women there are here, which led us to joke about the "idiot's view" type book I'll someday write about all the dorky things I've done with A5, and that I should call it "Alpha Five Girl Gone Wild (um, with code)" - so then I'm sitting there in bed watching Xbasic videos on my laptop, and I just couldn't stop laughing at all the evil possibilities for chapter titles. Oh my, I really do need to get out more, now don't I?

btw - dibs on that book name. I just might do it!

And of course - any comments on chapter titles, keep it clean people, there might be children lurking about!

[Humor Mode OFF]

Wendy out. Way out. ;-)

[iRadiate]

Re: Testing the &quot;Release Candidate&quot;

Some great advice there Jerry. It helps clarify the potential release candidate pitfalls.

By the way, one thing I do here before making any updates, official release or not, is to make a disk image of both my WAS and Development machines.
This is pretty much a bullet-proof way of getting back to a working system should anything go horribly wrong. We use Ghost here but there are several
imaging utilities that would work just as well like Acronis or Storagecraft ShadowProtect. It takes me under 30 minutes to do this but the peace of mind
is worth every second.

I haven't yet tried the new release candidate myself, but it's like a mighty beacon tempting me each time I start Alpha

Stephen

[WindForce]

Re: Testing the &quot;Release Candidate&quot;

Wendy!!
Too bad there is no "Like" button for posts here, enjoyed every bit of it :-)

Jaime

Thank you Jerry,

That tip about installing as a separate user sounds like an excellent way to go. Heck, even I know how to do that!

Would I be correct that using a staging site on the same hosted ISP server as the current build, there shouldn't be any issues or caveats (other than making sure you update the correct one, of course - the old "don't be an idiot" clause that applies to all of life)? They're completely separate if done correctly (I see separate session folders for each of mine...)?

[Editorial Mode ON]

For the record, I think it's excellent that you expose the work in progress to us like this.

I beta test extensively for another software company (different type of product altogether) and I've always found it leads me to understand the program better and that my feedback can lead to features or tweaks that are useful to me. People there periodically talk about beta testers getting discounts or some other compensation. The problem with that is, from my experience over a good 5 cycles, is that the quality of reports varies so wildly from tester to tester, and even cycle to cycle for the same tester, that it would simply result in people signing up to get the discount, without any good way to filter for quality. Picture any episode of Law & Order where some "helpful" citizen posts a reward for tips - they have to put on extra staff as the phone lines light up with 99.9% garbage. What I have found is that if I'm a very good tester - report everything I find and report in a way that's clean, clear and concise, the benefits are very real. Suddenly my suggestions and feedback are heard much more clearly. For me, getting a single feature from my wish list implemented, even a minor one, can be priceless. It's all about time. A single time saver in the program I use 60 hours a week, well that time adds up real fast. I don't think it's an official policy, just human nature - those being actual human beings on the decision making end, after all.

I also have had experiences with other software where something was released as "done", which in fact was still buggy as all get out. Autodesk is a huge company. I haven't use AutoCAD in years, so this may have changed, but way back when, we knew, we KNEW, not to use a new release for at least 6 months. It seemed to us that they'd release to hit the date, without regard to whether it was truly ready or not. It would be buggy buggy buggy, and the bug fixes were slow in coming - a deadly combination. Alpha Five's swift bug response is not the norm! I'd much much much rather be told honestly that it's still being worked on and given an avenue to see it and test it while still preserving my nice clean production environment - or even just get up to speed with the new features. So, thank you for that.

OK - that's my one and only two cents on that topic. As I said earlier, I'm not looking to get a long winded firestorm debate thing going. Having started this thread, and seeing a wee bit of angst perhaps, I thought wrapping it up with that other view might be good.

[Editorial Mode OFF]

[Humor mode ON]

Now I'm off to spend the day with Steve Workings, having just spent a good portion of the night with him. Relax Mrs. Workings! I'm talking about his videos. I'm evil. I was talking with the IADN roundtable group yesterday about how few women there are here, which led us to joke about the "idiot's view" type book I'll someday write about all the dorky things I've done with A5, and that I should call it "Alpha Five Girl Gone Wild (um, with code)" - so then I'm sitting there in bed watching Xbasic videos on my laptop, and I just couldn't stop laughing at all the evil possibilities for chapter titles. Oh my, I really do need to get out more, now don't I?

btw - dibs on that book name. I just might do it!

And of course - any comments on chapter titles, keep it clean people, there might be children lurking about!

[Humor Mode OFF]

Wendy out. Way out. ;-)

[MichaelCarroll]

Re: Testing the &quot;Release Candidate&quot;

The suggestion to install the release candidate in a separate folder is a sound one as we do that in testing all the time. While both instances will share the same registry settings, typically that should not cause any problems as most users use the same settings for both. The only "catch" occurs when applying a patch as the default install path will be the path of the last patch install, so it is important to know which instance is being updated and select the correct path for the instance being patched.

Almost all of the registry settings are unique to each user, so another way to segregate the settings is to set up another administrative user on the computer and install the release candidate under that user, or just install on a separate computer.

However, there are some very important caveats when using a release candidate build. A release candidate build may include features not supported in the release build. If you edit anything in the new build, it may not run under the release build. For example, a grid modified in the release candidate full build will run on that build, but may give an error if published to an Application server running a release build.

The release candidate build may only have slightly different support files such as JavaScript files. If you have tested a page or component build in the release candidate in a browser, you may need to clear the browser cache when running pages in the release build. Many of the JavaScript errors we see in Live Preview or published elements occur because of incorrect support files in the browser cache that have not been replaced.

You can usually roll back to an earlier build with no issues, but any changes made in a newer build may have to be re-saved in the older build. For that reason, it is a good idea to test the release candidate in a separate instance of a database.

As indicated in the prerelease notes, This is not an official patch, so you should not deploy this update to a production environment. The release candidate should ONLY be used for testing.

In any case, you should never publish anything built in one build to an application server running a different build. This will almost always cause problems.

If I can add to the great discussion. Using a virtual environment with frequent session saves, allows easy rollbacks to a version that is stable. VMWARE is a tester and developers best friend. I also keep my working directories on a network drive so roll backs do not affect my code. So in a nutshell I have backups and versions for my developer environment, and for my working data.