I'm planning a migration on a server from ColdFusion MX7 (Server 2003) to ColdFusion 11(Server 2012). There is a Other Server Where I need to migrate from ColdFusion 8 (Server 2008) to ColdFusion 11. Does my System effect in any way when upgrading like tags, or compatibility issues. Does anyone know which steps I should without effecting. I know about the code analyzer that we had in Cf administrator. I want to know if there is anything effected seriously when migrating.
Thanks in Advance
Kiran Kumar
The Code Analyzer helps in migrating your applications to ColdFusion 11 from earlier versions of ColdFusion. However, it checks the same for only two versions back. The Code Analyzer reviews the CFML pages that you specify and informs you of any potential compatibility issues. It detects unsupported and deprecated CFML features, and outlines the required implementation changes that ensure a smooth migration.
As far as the code compatibility is concerned, everything "should" work. However, it is recommended to check the code compatibility and deprecated tags (if any). You can refer to https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+Features & https://wikidocs.adobe.com/wiki/display/coldfusionen/Deprecated+tags,+attributes,+and+values.
I have briefly covered the entire Migration process here. So, will not iterate the same. Also, you can have a look at another helpful article for Migration Tweaks.
Having said that all, it's strongly recommended to test your website on the Testing/Development environment, before moving it on Production.
Hope this gives a better picture of the migration process.
I did the migration in the past, did not face important issue, as everyone have a different system the best solution would
- Backup
- Test the upgrade and see
if it's a production machine, you can copy your machine to a vm and test the upgrade there. it's may be a lot of work, but you can not know if you don't test
I am currently moving a ColdFusion 9 site to Coldfusion 11 and the way I tested it was to create a separate set of folders on the ms2013 server. I ran them side by side with a duplicate database with a different name for the test site.
I have moved sites up from 5 to 9 with few issues and the only one that really got me in ColdFusion 11 is dbtype in database functions. It has not only been depreciated but will always throw an error if found.
It also depends on how Coldfusion 11 will react to cfcs and other special tags if you use them. I don't so it was a snap.
Examples:
mydatabase
mydatabase1
mypagesfolder
mypagesfolder1
index.cfm
index1.cfm
Going live was a snap. I just renamed the folders, links*, dsn and renamed index1.cfm to index.cfm.
*Links only need to be changed if posting outside of folder and if so just the path.
Related
I am currently trying to upgrade a Sitecore installation from 7.5 to 8.1 Update 3 and I can't seem to figure out a good process that won't take weeks and weeks. I have posted questions on other blog posts and also to the official Sitecore Community site but have not really gotten any good feedback. Here is what I am trying to do.
I need to upgrade Sitecore from 7.5 to 8.1 Update 3. To do that it looks like I need to do 3 separate upgrades:
7.5 to 8.0 Initial Release
8.0 Initial Release to 8.1 Initial Release
8.1 Initial Release to 8.1 Update 3
In addition we are using both the Email Campaign Manager (ECM) and the Webforms for Marketers (WFFM) modules. Each of those modules has its own separate upgrade instructions.
Also we have servers in 3 different environments: 1 in DEV, 1 in QA and 3 in PROD (1 CM and 2 CD)
The upgrades of Sitecore itself are long and tedious and filled with many manual steps prone to error. I am already on my 3rd attempt to upgrade my DEV site and it seems every time I do it I get about half way through and I run in to lots of errors. In addition the instructions for upgrading ECM/EXM seem to not allow you to skip to major releases. So to upgrade EXM itself I am going to have to do 10 individual upgrades!!!
I am trying desperately to figure out if there are any shorter ways to accomplish this upgrade. This is so complicated and tedious that I feel like it will take me one or two days just to upgrade the DEV site. Then another one or two days to upgrade the QA site - assuming I don't run in to any errors that I can't figure out.
Then after that I have absolutely no idea how I am going to upgrade PROD. I have a CM server and 2 CD servers. There's no way I can freeze content entry and editing for a week while I do the upgrade. Plus we have some user generated content like user registrations and order entries on the site. How can I upgrade PROD and not lose registrations and order entries and other user generated content?
I was hoping that there would be some easier way of doing a Sitecore upgrade from one major version to the next but I can't seem to figure it out. No matter what I try it is incredibly complex and manual and prone to error.
Any help is appreciated.
Corey
One option could also be installing a new version of Sitecore 8.1 update 3 and run a database comparison tool (such as RAZL) to get across the items in your new Sitecore instance.
You could get the items across using the regular Sitecore packages although that's more time-consuming unless you automate that using something like Sitecore Ship or Courier.
You'll also need to check your code of course, any config changes you're patching in etc. still will have to be tested.
Mind you, this is not recommended practice for reasons you can find in the blogpost jammykam posted in a comment (http://www.seanholmesby.com/the-truth-about-sitecore-upgrades/)
There's rumors of an Express upgrade tool in 8.2 that will allow you to upgrade directly from an old version. I don't have an official source, but there's a few blog posts about this, this for example: http://kverheire.blogspot.com.au/2016/06/sitecore-82-in-depth-preview-83-update.html
I believe the people who actually have more info on that are bound by NDA - so you'd have to ask Sitecore directly for more info.
If you can't wait for 8.2 - then you can also create new blank environments of a newer version and write your own processes for migrating data across. Not sure how easy this will be with EXM, WFFM, or Analytics though.
I have often faced the issue ‘Service unavailable’ in ColdFusion website and need to restart the service manually. Sometimes, also need to restart the host computer.
I checked Event Viewer but I do not find any error related ColdFusion.
I am not familiar with ColdFusion.
Kindly help me. I would like to check why it happens and to solve this issue.
ColdFusion Version 8
Windows Server 2008 R2 Standard - Windows 7, 64bit
IIS Version 7.5
Thank you.
To find out what is actually crashing your CF server you may find information in the "out" log. Look in the /runtime/logs directory for a file called "coldfusion-out.log" or something similar. This is where standard out goes in a running CF application. There is also a /logs directory in your application that may give additional information.
Finally, you may have a hotspot error - an abend. Look in the /runtime/bin directory for a file similar to hs_err_pidXXX.log" (where XXX is some number). If you do have such an error take a quick look to see if it is an "out of memory" error. That's the most common.
I have a post on where all those log files are located. It is from the CF8/CF9 days so it may be useful to you. Of course everyone will tell you to upgrade as well. :) Good luck!
There are two places to look with problem like this: the application server behind CF (JRun for CF8) is the connector between CF and IIS. Adobe CF uses old (IIS6?) style ISAPI connectors that may need to be rebuilt - later versions of CF have a 'rebuild connectors' batch file in cfusion\bin\connectors (something like IIS_connector.bat) but it has been a while since I've had CF8 to look at. At the very least, be certain that you have the last CF8 update from Adobe as they sometimes want you to rebuild connectors after installing them.
A better solution for newer versions of CF (10+) is to use Bilal's Boncode AJP connector - I don't think it supports CF8 but haven't tried it.
CF 8's End-Of-Life was over four years ago and later versions stopped using JRun in favor of Tomcat, which is a bit easier to troubelshoot. If you have a development environment available, you might try running your codebase on CF10 or CF11; if you have to support this application for the foreseeable future, better to do it on something resembling a current version of CF. You could also have a look at Lucee 4.5 for an OSS alternative.
Recently Sitecore 8 has released and it has came up with lot of exciting new features. So our team decided to move from Sitecore 6.6 to Sitecore 8. Before migrating, i would like to know what all things i should be having in handy. Such as, .net Framework, Hardware configuration, environment etc.
Also, i would like to know the procedure to migrate from 6.6 to 8? I, never involved in sitecore migration project before. Please suggest me some good articles or post here your thoughts.
Thanks in advance. :)
See the Sitecore Compatibility Table for the .NET Framework, SQL Server version and Windows version.
Two common approaches.
1) Follow the Sitecore upgrade path.
2) Package the content, and start with a clean install.
Currently I working on a upgrade with an scripted upgrade that follow the Sitecore path. So I can easy repeat the steps and have the latest content in the databases.
I have some of my findings put down here Sitecore update and modules this article contain also a Related links section. Such as the upgrade white paper from Varun
Depending on how 'cluttered' your existing instance is, you may also want to consider installing a fresh copy of Sitecore 8 and then migrate your data/code to avoid all the hops that would be necessary to get to 8.
May be the following blog might help. Take a look at it.
https://varunvns.wordpress.com/2014/11/11/sitecore-version-upgrade-whitepaper/
I would recommend you make a backup of your site to use as a "sandbox" for the upgrade. Copy your databases and the web root for your site to a new location and then set up an IIS site with appropriate permissions pointing to your copy, and change your connection strings in the copy to point to a copy of the databases you backed up.
Perform the update there and ensure everything is working correctly. Work slowly to make sure you are following instructions correctly and note any special actions you had to take to perform the upgrade. Once you have it upgraded, perform the same process on the "real" site.
If you work with a Sitecore partner, I would highly encourage you to discuss the process with them to learn more specifics about the risks and challenges you may encounter during your upgrade.
The general guidance appears to be to install Sitecore into one folder, e.g. D:\Websites\MyWebSite and then create your Visual Studio project in a separate folder, e.g. C:\Projects\MyWebProject. You would then publish your custom code into the Sitecore folder from Visual Studio (This video explains what I’m describing https://www.youtube.com/watch?v=i3Mwcphtz4w around 13 mins in).
I have the following questions:-
Do people only store their Visual Studio project in source countrol and not the Sitecore code?
The publish option from VS into the Sitecore folder only has options for adding files or deleting anything not in the VS project. How would files removed from the VS project ever get deleted without doing it manually?
We use web-deploy to publish sites to staging and live environments. In this scenario would you publish from your VS project or would you set up a way to publish the Sitecore folder (if so how)?
Is this actually a good set up to have or do you do something different?
I did a lot of research on this when we started Sitecore development a couple of years ago. I remember reading a post from Sean Kearney that made a lot of sense to me: http://seankearney.com/post/Visual-Studio-Projects-and-Sitecore
We ended up using this approach for both large and small scale projects and it has been great. You will also want to look at a couple of other tools:
Team Development for Sitecore (TDS) from Hedgehog Development (http://www.hhogdev.com/products/team-development-for-sitecore/overview.aspx)
CopySauce from Igloo (http://www.igloo.com.au/blog/copysauce-igloos-sitecore-development-utility/)
SitecoreRocks for Visual Studio
So to answer your questions:
All of your code and some of the Sitecore items are stored in source control. The approach you want to take is to only store new Sitecore items (layouts, sublayouts, templates, etc) that you create along with any items you may need to customize. You do not need to store all of the sitecore source, content or modules...just what you would need to reapply to get a fresh environment up-to-date. You can manage this manually but a tool like TDS makes this MUCH easier.
We use TDS to manage the publish/deploy to each of our environments. TDS has configurable settings for handling items that have been deleted, including the ability to move it to the Sitecore recycle bin or simply remove it. You have to be careful with this but it does work.
We use a separate build environment to assemble and run deployments using TDS and Jenkins. Basically, all of the code is retrieved from the source control system to the Sitecore server and built using MSBuild and TDS. In most cases we use a webdeploy directly to the Sitecore webroot, but for production we build TDS packages and then run them on each Content Delivery Server
We have used this setup for 7 sitecore projects so far and I am very happy with how it has worked out. We have questioned whether TDS is worth the license fee but the answer always comes back as a yes. The alternative is not very appealing for our development staff and time savings far out-weigh the costs.
Everything is stored in Source Control!... just not always in the same area as they reside on the web server. Storing the Sitecore folder in source control is a good idea as there are changes that you will have as you install modules, but you do NOT add the Sitecore folder as part of your solution/project and should really be there to pull from if need be and not something that is even tracked/monitored.
Once Sitecore is installed, create a new project that resides in the website folder and only add things like the properties folder, layouts, xml and other folders that you want. I don't even include the app_config in my project. Oh and to be clear, it's probably best to just keep the Sitecore folder as a sort of reference folder in your source control but not as part of your website trunk. We have it on the ignore list for website folder in source control. However, that being said, keep in mind that you will NEED to have it in your website folder.
Technically speaking, the recommended approach is to install Sitecore on to the server itself as a stand alone empty instance.. like using the installer with the client mode (not full) so that you get the framework for an empty site in place. Then you can create the deployment package/packages/whatever and it will all be your own code. You should really never have to mess with changing/removing the base Sitecore file system manually.
See above. Generally speaking, unless you have a reason to do so: install Sitecore as an empty instance... then manage your code/files via deployment and just leave the Sitecore folder files alone. You will have very little reason to ever touch them or the Sitecore folder itself outside of an upgrade.
Adding Sitecore itself to source control should be avoided, since you won't be deploying Sitecore as part of your implementation. For modifications to Sitecore itself, you would need a way of handling those inside your implementation, but the config patch system and other mechanisms provide the means for this.
Redundant files in the web site folder will only be a real problem in your development environment. When publishing to a demo environment or to a live environment, you will only publish the material that you actually want. And the deployment-based setup opens up the possibility of always starting from a clean Sitecore installation - as long as you include your Sitecore modifications as part of your implementation (which is not covered in the video). So there is little risk of this being a problem in real life, and the development method in the video makes eliminating this risk entirely possible.
The Sitecore installation should be handled outside of the deployment of your implementation.
It's a good setup, because the method in the video is the method Sitecore recommends for development, and it is also the method Sitecore teaches to developers in development courses. The most obvious advantages of this method are
Clean separation between your web site implementation and the Sitecore installation. There is no risk of accidentally mangling the Sitecore installation, and there is no risk of forgetting unmanaged manual modifications to Sitecore that are needed to run your site. This separation is hard to accomplish if you're not using the method in the video.
By using publishing to deploy your implementation, you know that your implementation is deployable on top of a clean Sitecore installation - and works. This means when deploying to a production or demo server in the future, things will work the same and there will be no surprises. This is very hard to be confident about if you're not using the method in the video.
To test your implementation on a different version of Sitecore, you can just deploy to a clean installation of a different version. This is very hard to test if you're not using the method in the video.
There is sample source code for the video on GitHub, along with instructions on how to set up the development environment, including the publishing parts. This sample source directly and indirectly answers some of your questions.
I just finished a Django app that I want to get some outside user feedback on. I'd like to launch one version and then fork a private version so I can incorporate feedback and add more features. I'm planning to do lots of small iterations of this process. I'm new to web development; how do websites typically do this? Is it simply a matter of copying my Django project folder to another directory, launching the server there, and continuing my dev work in the original directory? Or would I want to use a version control system instead? My intuition is that it's the latter, but if so, it seems like a huge topic with many uses (e.g. collaboration, which doesn't apply here) and I don't really know where to start.
1) Seperate URLs www.yoursite.com vs test.yoursite.com. you can also do www.yoursite.com and www.yoursite.com/development, etc.. You could also create a /beta or /staging..
2) Keep seperate databases, one for production, and one for development. Write a script that will copy your live database into a dev database. Keep one database for each type of site you create. (You may want to create a beta or staging database for your tester).. Do your own work in the dev database. If you change the database structure, save the changes as a .sql file that can be loaded and run on the live site database when you turn those changes live.
3) Merge features into your different sites with version control. I am currently playing with a subversion setup for web apps that has my stable (trunk), one for staging, and one for development. Development tags + branches get merged into staging, and then staging tags/branches get merged into stable. Version control will let you manage your source code in any way you want. You will have to find a methodology that works for you and use it.
4) Consider build automation. It will publish your site for you automatically. Take a look at http://ant.apache.org/. It can drive a lot of automatically checking out your code and uploading it to each specific site as you might need.
5) Toy of the month: There is a utility called cUrl that you may find valuable. It does a lot from the command line. This might be okay for you to do in case you don't want to use all or any of Ant.
Good luck!
You would typically use version control, and have two domains: your-site.com and test.your-site.com. Then your-site.com would always update to trunk which is the current latest, shipping version. You would do your development in a branch of trunk and test.your-site.com would update to that. Then you periodically merge changes from your development branch to trunk.
Jas Panesar has the best answer if you are asking this from a development standpoint, certainly. That is, if you're just asking how to easily keep your new developments separate from the site that is already running. However, if your question was actually asking how to run both versions simultaniously, then here's my two cents.
Your setup has a lot to do with this, but I always recommend running process-based web servers in the first place. That is, not to use threaded servers (less relevant to this question) and not embedding in the web server (that is, not using mod_python, which is the relevant part here). So, you have one or more processes getting HTTP requests from your web server (Apache, Nginx, Lighttpd, etc.). Now, when you want to try something out live, without affecting your normal running site, you can bring up a process serving requests that never gets the regular requests proxied to it like the others do. That is, normal users don't see it.
You can setup a subdomain that points to this one, and you can install middleware that redirects "special" user to the beta version. This allows you to unroll new features to some users, but not others.
Now, the biggest issues come with database changes. Schema migration is a big deal and something most of us never pay attention to. I think that running side-by-side is great, because it forces you to do schema migrations correctly. That is, you can't just shut everything down and run lengthy schema changes before bringing it back up. You'd never see any remotely important site doing that.
The key is those small steps. You need to always have two versions of your code able to access the same database, so changes you make for the new code need to not break the old code. This breaks down into a few steps you can always make:
You can add a column with a default value, or that is optional. The new code can use it, and the old code can ignore it.
You can update the live version with code that knows to use a new column, at which point you can make it required.
You can make the new version ignore a column, and when it becomes the main version, you can delete that column.
You can make these small steps to migrate between any schemas. You can iteratively add a new column that replaces an old one, roll out the new code, and remove the old column, all without interrupting service.
That said, its your first web app? You can probably break it. You probably have few users :-) But, it is fantastic you're even asking this question. Many "professionals" fair to ever ask it, and even then fewer answer it.
What I do is have an export a copy of my SVN repository and put the files on the live production server, and then keep a virtual machine with a development working copy, and submit the changes to the repo when Im done.