i am using fly way to migrate the core product from older version to newer version. This work wonderful.
But I have a case, where we want to migrate customization specific script on top of Core product version. As you know, each client may have different customization.
For example.
Say core version is 2.2.1.
Customization 1 version is 1.0
Customization 2 version is 1.0
Now i would like to apply flyway similar to this
V__description.sql
For the above example, it would be like
V2.2.1_1_1.0__ThisIsCusotmization1.sql
V2.2.1_2_1.0__ThisIsCusotmization2.sql
This is little cumbersome for us.
Is this possible to use alphabets/alpha-numeric in version names like below?
V2.2.1_CUST1_1.0__ThisIsCusotmization1.sql
V2.2.1_CUST2_1.0__ThisIsCusotmization2.sql
V2.2.1_RC1_1.0__ThisIsCusotmization1.sql
Note: Moreover, I could nt see any significance of using prefix (V) here. Please let me know its purpose. Also please let me know whehter we can use more than one prefix like one for core product and other for customization.
From the sound of your question, you probably should go for two Flyway instances. One for core, managing only these changes and another one for the customization.
Each could then be configured with a different location to resolve the migrations from.
Related
I have recently started learning about Alfresco Content Service.
I have some questions:
My understanding is that the standard way to add customization is to create AMP's.
Why create an amps for each customization instead of adding it directly to the configurations of ACS? Are there some benefits like not having to restart the service or something?
If apply_amps adds all custom amps to the alfresco server (.war files), won't there be a risk of customizations writing over each other?
E.g if two different amps change the same standard button in the share service.
I have found that there are 2 ways to add these customizations as well:
Add dependency to the pom file. (works only for .jar)
Actually compile the .amp and move it to the correct folder and run apply_amps.sh.
From the documentation it seems to my like AMP-files used to be the standard way of adding customization but that there have now been a move away from this in favor of using regular jar files and eventually in 7.1 and forward use JSON instead.
Yet other tutorials I find mentions things like "always use .amp". Which then seems strange if it contradicts the information on the official documentation.
Also I found something about adding amps through the share interface? Or must they always be added when building the server (.war)?
Could someone provide me with a thorough explanation of the best practice for applying customizations to the alfresco content service? Preferably with details regarding a live production setting.
Thanks for helping me make some of this clearer.
I'll try to give you helpful answers:
Making app packages (APMs or JARs) is much better than changing config manually. It's good for versioning, portability (TEST vs PROD or between projects), composition (you can add some addons witch are often very useful)... It is standard and good way how to build a web app.
About conflict of customizations, I'm not sure how it works. Is good practise always use own namespace for every AMP.
If AMPs write to the same file, result is always append (share-config-custom.xml can get be very big).
Problem about JARs and AMPs is simple. Old version of Alfresco supports more AMPs than JARs. Now it does not matter with way you use. Try to look inside these packages they look very similarly.
I never heard about adding AMPs through the share interface. Have you some source? Only thing which is similar is creating content model through Model manager (https://docs.alfresco.com/content-services/latest/tutorial/model/)
I use for PROD combination of AMPs and JARs. I have a lot of legacy code and addons in AMPs and new things in JARs. Alfresco work with them same...
We are going to build something like cratejoy.com, but don't want spend lot's of time building which is already builded before for developers.
I was going through sonata and sylius, but not sure if we can build subscription based model with one of them. If yes we can, then which would be best to use? or should we just build complete custom solution, because it involve b2b solution.
What we will be building?
Basically e-commerce software like any os-commerce shopping system, but the only difference is, we will be adding subscription on each product.
So let's say, if you order a product, we will ship it to you every month to your door step.
but we are building this as service, so many people can just create their site and start using our tools to start selling there products.
I might be a little biased towards Sylius, as I work with it constantly - I've tried using Sonata bundles in projects before but failed in making use of them.
Reasons for using Sylius are that it's heavily decoupled and customizable, which is exactly what you want if you need an e-commerce solution that is not the conventional "add product to basket, pay for it once" model.
There are two approaches you can take to use Sylius: Either use the full stack application and customize it, which is the most common approach and better supported. The other approach is to install Sylius like a library rather than an application and build the application and frontend yourself, using Sylius classes and services when you need to (which is what I do).
Things to be careful when using Sylius are that it's still in beta, with breaking changes occurring between releases. Also the documentation is very incomplete or outdated (something I plan to help improve), with the exception of Resource and ResourceBundle - these packages are the most important part of Sylius and are therefore very well documented. For your project, I recommend the first option.
For subscriptions, areas of Sylius you want to look at configuring and extending are OrderBundle, PricingBundle and PaymentBundle. If you're very familiar with Symfony, this should be straightforward.
what is the best way to Import content from Tridion 5.2 to Tridion 2011 SP1, content porter? or Kapow
To upgrade the DB you would have to follow this path: 5.2 => 5.2 SP1 => 5.3 SP1 => 2011 SP1. This information can be found in the documentation available on www.sdltridionworld.com
Additionally you would need to:
1.- Rebuild store procedures.
2.- Rebuild search index.
3.- Optimize stats.
In case you want to migrate only bits and pieces you are looking into extract content from 5.2 using business connector and then importing this into 2011 using CoreService.
What about upgrading the database? Or are you going to sanitize content?
I would probably try Content Porter (due to cost) but take into attention all dependencies that might come with it.
Do you have two different Tridion environments set-up already? Is the content in your 5.2 environment old? Has it seen a lot of updates already? Does the code remain exactly the same (vbscript?) Does your client really want all the content, or just parts of it?
If it really is just a case of an upgrade without anything changes in code, design or implementation you should use Asier Fernandez's solution with the database upgrade.
Anything else that is going to be an upgrade of Tridion systems, but with many other site changes you should considers a more manual approach (cheaper in the end) Bart Koopman once wrote a ncie blog about it: http://www.tridiondeveloper.com/how-to-say-goodbye-to-your-migration-tool
I would like to ask why you think the sdl tridion advised way (database upgrade) is not in your options, as that is really the most safe way (if upgrade is what your goal is)
If you are also planning on cleaning up your database then i suggest to first clean up unnesesary items (components, pages, keywords, templates, schemas etcetc). When you are not able to remove items, use WhereUsed as you need to cleanup or disconnect dependancies. Don't think that a CP export->import will clean up the items that you could not delete during your cleanup, if you were not able to do it manually, cp will also not be able to, it will simply add the items to the package.
In my eyes, the only reason for a CP migration for upgrade is to cleanup legacy issues from older versions (db upgrade will keep them) but keep in mind, broken relations/items will fail in CP and you will need to manually create them in the target system, but this way you can get rid of legacy issues that will not go away
In my eyes, for upgrade only, use db upgrade, less effort, fully supported by sdlt support.
And my advice is to seperate an upgrade from ANY other requests, like new layouts, new functionality or cleanup, that way testing and bugtracking will be lot easier
I was wondering how teams that develop sites using Drupal (or any other CMS) integrate version control, subversion, git or similar, into their workflow. You'd obviously want your custom code and theme files under version control but when you use a CMS such as Drupal a lot of the work consists of configuring modules and settings all of which is stored in the database.
So when you are a team of developers, how do you collaborate on a project like this? Dumping the database into a file and putting that file under version control might work I guess, but when the site is live the client is constantly adding content which makes syncing a bit problematic.
I'd love to know how others are doing this.
You are correct that this is an issue for Drupal--version control works fine until you turn the site over to your client or open it up to users.
Your question seems like a more specific version of this one, which touched on version control in the Drupal workflow. You may find some answers there that help.
For some projects, I have exported all of the views to code, using that feature of the Views module, and I have one project where all of the blocks have been exported, as well. (Although that was a development exercise and not a customary thing to do with blocks.)
Take a look at the work that Development Seed is doing to work around this problem. They are leading the development of the Context, Features, and Spaces modules that work together to store configuration data in modules (outside of the DB) so that it can be versioned with the code.
There is a Drupal group called Packaging & Deployment for discussing the various solutions that are being developed for this issue.
Right now there are a lot of efforts towards creating something that will handle the dev -> production difficulties with drupal in relation to the database. Features, that flaminglogos mentioned is one, but I feel that is more focused on creating stand alone projects, ie ones that would be installed on many sites.
For simple maintaining you dev and prod databases I'd take a look at http://drupal.org/project/deploy and http://drupal.org/project/dbscripts. They support syncing and merging db side drupal config data.
I can't guarantee they are ready for prime time though...
There is a lot of effort of shipping the next drupal version with configuration in code. That's is the key to have it in a version system.
For now you can use the features module, with that you can export things like content types, views, etc. to code, and then compare, version and revert it as you need.
I am creating a web app that allows people to debate topics. I started prototyping with Django and have a functional app. I have not yet decided on what framework to use.
I've read about Plone the app and Plone the framework. I just can't seem to find any online documentation on using Plone as a framework. I'm looking for a tutorial or something that will show me how to build a web app starting with Plone. I just want to evaluate Plone before I choose my framework.
Anyone have any refs or recommendations on learning how to use Plone as a framework?
You should start here:
http://plone.org/documentation
A really good book is:
http://www.packtpub.com/Professional-Plone-web-applications-CMS/book
Plone is build on Zope Application Server (zope.org). You should read into the zope book too. Its free.
The IRC Channel (#plone) on freenode is full of experts that are willing to help. They like to discuss with :)
Don't use Plone as Framework.
Plone is an CMS. You can use it as framework,You can use Zope2 application server + Zope3 component architecture but I don't recomended to do this. Plone was designed to be a CMS so why You want use it as framework?
Why you shouldn't use Plone as framework?:
Plone is Slow!!!
30 sec. on every restart is too much. When You change something, you need restart. Autorestart(http://plone.org/products/collective.autorestart) doesn't help, you still need to restart Plone any time You change a zcml, portlet's code and sometime with python code.
Plone is too complex.
So big code base. Different coding styles (old Zope2, new component base Zope3, some parts are written with Grok).
You will need write xml (Generic Setup).
Nobody can say what you must use Archetypes, Formlib, z3c.form or Dexterity?
Plone doesn't have good documentation. Too much old documentation (plone.org/documentation) and there is no place where you can read what is the right way to do. The only good documentation is in Martin Aspeli's book (martinaspeli.net/plone-book) but you will need more and this book isn't open, so You will need buy it.
Plone has so many products but if you need really stable and quality stuff you will need write your own.
Plone is Slow!!! Forget test driven development.
I think that the most important factor in choosing a framework is the existence of good documentation. If you can't find good docs for using plone in the way that you want without having to ask here first, that's all the "evaluation" you need.
I'd stick with Django.