We had deployed jboss4.2.3GA in 2012,and now we want to upgrade to Wildfly,but now we have no sufficient technical to do that.so someone can tell what we can to step by step ? and are there any technology guide?
We have compared the document structures of the two versions, but they are far different. So we want to find a guide that can actually guide us step by step. I wonder if there is such a document?
Related
Which is the more feasible strategy for version upgrades when you are multiple versions behind. For example from 6.4 to 2005.
Should we really do a version by version approach as SAP suggests. I understand it's recommended way but still.
Any one can share their experience regarding this?
What difficulties could be faced when directly migrating multiple versions?
Thanks!
There are several approaches you can take. Which one you take depends on the knowledge your team has and with the amount of customizations you already performed.
Step by Step
This is the recommended way by SAP. This is a more secure strategy, where it's very clear what changed between different versions. With every version, you will experience build failures, startup failures and possibly even data issues that need to be migrated. But it's very clear what version caused those issues. With the SAP help and the upgrade notes, you should be able to easily find what was changed, and how to fix it. Disadvantage with this approach is that you need to download, unzip and build for every version, and that takes time. Sometimes you even need to fix the same code twice, when the implentation was changed multiple times
One Shot
With this approach, you go straight to the latest version. You just put your custom code in the latest version and just see what build failures you get.
With this approach, it will be harder to figure out what exact version upgrade caused a specific issue. You should still check all upgrade notes, to make sure that no migrations are needed. Advantage is that you only perform everything once. If you have an experienced team, this is a feasable approach. If you have a new team, be carefull with this approach. You might encounter some difficult errors where you won't be sure what version caused them, so finding info in the SAP help might be harder
Hybrid approach
A third option would be a hybrid approach, where you upgrade several versions at once (For example to versions that contain big changes, like with the addition of backoffice in 6.3). This makes it easier to apply changes for those big changes, while you don't have to go through every version one by one.
Conclusion
I've tried all approaches in the past. The step by step approach takes a lot of time, but makes the changes easier and clearer. With the One Shot approach, you only need to download the latest version, but it might be somewhat harder to find the bugs. If you have an experienced team, you should go for the one shot approach. When you are a lot of versions behind and there were big changes, you could go for the hybrid approach
I had a similar requirement of upgrading from version 6.2 to 2005, I went with the One-Shot approach as explained by Yoni, and the biggest challenge I faced was due to Java version change.
I believe One-Shot approach and Step by Step approach will take a similar amount of time in the major version upgrade, though Step by Step approach is safe but redundant. My personal favorite is One-Shot.
I recently did a platform upgrade from hybris 6.7 to 2005 and did it step by step, mainly because of the java version change and, other than that, there were certain migration steps in each intermediate version that were needed to be done. Also the customer had a lot of custom promotion rules and they needed some special care.
In my case, the process in each step was this:
Upgrade to new version - there is an help.sap.com page for each step, I recommend you follow it and go through each of the section to see what applies to your project, e.g Upgrading Platform from 6.7 to 1808
Compile the project - some deprecated things will be removed in some steps and you have to refactor where needed. This step took me the most amount of time
Start the hybris server - after you finish the refactoring and your project builds successfully with ant clean all there is the possibility that the platform will fail to start due to some (now) incorrect xml config. The "good" part here is that you can see in the console what the problem is and the fix should go faster than the previous step.
Perform the necessary upgrade steps - here is the tricky part, once your platform starts you have to perform the necessary upgrade steps for each extension and add-on that needs it, otherwise you risk working with some broken business logic. You need to do some regression tests and check that everything works as it should.
All in all, an upgrade takes time and depends on how many versions you have to go through, but I think taking it step by step is the most efficient way to accomplish it.
I'm looking for a place to run the perforce service on, since their Helix Cloud has been in beta since early 2015, and doesn't seem like it will leave said beta any time soon.
The problem is that I have little understanding of the whole gimmick. I basically need an engine that can run a service and can store data, so that I and my colleague can connect to it remotely and version our project. I've read their documentation regarding Big Data and Compute Engines, and I still can't figure it out. One seems massive, the other seems more appropriate for a gaming server. I suppose Storage would be the right one but I'm not sure that one can run services.
So do I run it on a VM and turn it off/on when done/using it? Or is there a better way at versioning with perforce in the cloud. Seems kinda pointless running a VM to turn it on and off, since that's what i'm currently doing with my local machine anyway. Unless there is a better solution.
I hope that's the right spot to ask about this, I was referred here by their support page.
PS: We are a small team,50-100 Gigs of versioning storage will last us for ages, please when answering don't assume I need something fancier than it needs to be.
After experimenting for a few days and reading the documentation, I have come to the conclusion that the Compute Engine is the only on on GCP that can run a service. Ended up configin a CentOS and keeping it there.
Several days ago, Mirth Connect version 3.3.0 was released. Noting the great new features, we decided to upgrade immediately (just days after the initial release). We followed these Upgrade Guide instructions during the upgrade. However, the specifics of upgrading from 3.2 to 3.3 are missing from these Upgrade Guide, so we did not suspect much to change on the way Mirth should be implemented...
During this process, we ran into a handful of issues that caused our production channels to go down for several hours (†).
It would have been really nice to have specific information for this upgrade. Some issues that would have been really useful to know beforehand (just examples, no need to actually answer):
Are you changing the default toString() method for objects/arrays to return JSON representations?
Does this upgrade include a db migration, meaning we can't revert to
previous version once upgraded?
Because code templates are now children of "libraries", will we need to access the code template through the library, or will we be able to call it directly (as it was in 3.2)?
A solid documentation like this would have allowed us to understand the full gravity of what needs to be accounted for when upgrading. Typically, Mirth has some documentation for each minor release. But even then, the documentation is very terse. Would it be possible for the Mirth team to start being very explicit with what the upgrade entails?
The Rails Upgrade Guide (obviously much larger team, so can spend more bandwidth on this spec) provides a really great example of what an upgrade guide should entail.
† yes, yes, I learned my lesson, I won't upgrade immediately to production anymore
The Release Notes page will give the lowest level of changes to the application, but you're right in that a better documentation is needed.
Can anyone suggest books to understand writing rules looking upon business process and integrating that into ESB? I know how to write a rule and run a java application. That is where I reached for last 2 days. Anything useful will help me in catching up with all these.
Did you check the jbpm.org documentation site and the drools.org documentation site?
I'm promoting a Community Training Course about Drools and jBPM5 you can find it here:
http://salaboy.com/2011/01/24/announcing-jbpm5-community-training/
http://salaboy.com/2011/02/23/drools-5-community-training-announced-roadmap/
If you find it useful please give us feedback.
The general consensus is that devlopment of MOSS publishing sites, should be done using site definitions, Solutions, Features but due to project timescales we had to do all list/site column/content type/master page development using the SharePoint UI and SPD. We then used the contentdeployment wizard to migrate everything from devlopment.
Having done this, the future plan is to possibly, given the budget, change what has been built to use a site definition and features to get in line with best practices.
Has anyone done anything similar or have any tips on how best to plan for this?
Kind Regards
This is somewhat dependent on how large and complex your solution is. I was in the same situation with a project I started to work in. They initially started to do everything in SharePoint Designer. But when I was thrown in to the project, I decided to scrap all those changes, starting from the requirements and build up everything as site definitions/solutions/features in Visual Studio. In this case, it was feasible since the customizations were not too complex.
You can take a look at the SharePoint Solutions Generator, to see if that could help you as well. It can give you at least a good starting point.