Recently our development team are wanting to use Flyway as database deployment tool. Flyway requires some version numbers to be prepended to the files. Developers want to check in the version pre-pended files into the Clearcase. Our argument has been why do you need to version the files inside the versioning tool.
Has anyone used Flyway and Clearcase? If so how are you all doing it?
Thanks in advance.
You would need to version those files if you cannot generate them.
But you shouldn't version them with version number, but rather put that information in an extra file, also versioned, which you can use in order to copy the other files in a separate folder, with the right naming convention.
Related
I have a WPF application.. I need to create 3 setups, each setup is for an environment(development, staging and production), I've put each environment configuration into App.config file of my main UI project. I need Installshield to pull the appropriate configuration file while creating the setup file.
A question: Is there a way to do it differently?
thanks,
There are several approaches you could take. Here's one:
In recent versions of InstallShield (Professional and higher editions), you can override Path Variables on a per-Release basis. If you craft your source filesystem and source path correctly, this should let you select from multiple source app.config files just by building a different release.
I currently have an application that runs on jfreechart-1.0.13, and would like to upgrade it to run on jfreechart-1.0.17(latest).
So I am wondering how can I integrate the latest version of jfreechart with my current application?
In this application, I have build.xml (which is common to jfreechart I notice). Do I need to just update the urls in here to point to the latest jar file?
How can I upgrade my existing application to use the latest version of jfreechart?
As with everything Java, at the very least you'll need to replace the old jar files with the new. Whether that means physically swapping them out in your project, or pointing some configuration file to point to other files depends on your environment.
After that, all bets are off as there may well have been API changes that require changes to your code for things to compile, let alone run.
build.xml is typically an ANT file, and would have no influence on what jar files are included as ANT expects all those to be available already.
Of course other systems can use the same name, impossible to tell from here :)
IOW know your environment, do what is needed in your environment, then TEST.
What is the best way to upgrade a local development version of DNN source without destroying the database (pages, settings, module settings, etc..)?
I'm currently moving from 07.00.XX to 07.02.00 and there is a tremendous amount of refactoring, seems impossible to just overlay the source.
Is there a way I can do this with preservation of all settings, etc....or will I need to rebuild parts of the site?
Since you are using the SOURCE package, you should be able to simply copy the SOURCE files from the ZIP file you download, over all of the existing files.
You might make sure that the new SOURCE package doesn't have a web.config file, if it does, remove/rename that so that it doesn't replace your existing web.config file, and thus saving your MachineKeys and connection strings.
Back up the FILES and Database before you attempt this however, just to be safe.
After the copy you might have to build the solution before the upgrade will work.
I typically don't recommend using the SOURCE package for DNN, unless you absolutely need to make changes (not recommended) to the source, it isn't necessary for doing Module Development or skinning.
I am running Sitecore 6.5
I have two installations of Sitecore and want to transfer a whole site from one installation to another.
Have found a few articles that go into Serialization and Creating a Package although they don't go into detail about how these two fit together.
How do I transfer a site from one installation to another?
thanks.
Create a package with the package designer.
include these items and their children with the button "items statically". if you have placed your solution specific item in folders, it is only needed to include these.
/sitecore/content
/sitecore/layout
/sitecore/media library
/sitecore/templates/ (only take the templates you have created. e.g. the folder user defined
using the button "files statically", include the folders with you have solution specific changes to like:
/bin
/layouts
/app.config/include (only take the files changed in the solution,
compared to a default sitecore installation)
web.config (if you have made changes to this, compared to default
sitecore web.config)
if you have any user accounts you want to transfer to, you can include them with "security accounts".
then generate zip file and install on empty sitecore and full publish :)
If your systems are similar enough, you may want to consider moving the Sitecore DBs via backup/restore (in SQL) and copying over filesystem assets. Generally I find this faster and less prone to user error than creating/installing very large packages. (Just remember to take back-ups first.)
Large packages have a tendency to break, one option would be to look into this:
http://www.hhogdev.com/Products/Team-Development-for-Sitecore/Overview.aspx
TDS can sync all your items to XML on your dev box and from that you can create a different sort of installation package which is significantly more robust than a regular package you create through the Sitecore desktop. It's the same sort of package that Sitecore use when you upgrade versions.
I believe there is a 60 day trial on this product so plenty of time to try it out.
Note: when transferring user accounts, passwords will not be migrated when using either packages or serialization.
Solution is here - cowboy-aspx from Sitecore :)
https://kb.sitecore.net/articles/242631
RPM seems to be pretty good at checking dependencies and handling individual file updates, but what is the best practice for handling cumulative updates to, say, a relational database across multiple versions?
For instance, say you have product Foo with versions 1.2.1, 1.2.2, 1.2.3, and 1.3.0. In each of these, there were database schema changes that required SQL upgrade scripts. Running each upgrade script in sequence is required to get up to the current version of the schema.
Say a customer has 1.2.2 installed and wants to upgrade to 1.3.0. How can one structure the RPM package so that you have the appropriate scripts available and execute the correct upgrade scripts against the database? In this instance, you'd want to execute the upgrade scripts for 1.2.3 and 1.3.0, but not the ones for 1.2.1 or 1.2.2. since those have presumably already been executed.
One alternative is to require upgrading to each intermediate version in sequence, forcing the user in this example to upgrade to 1.2.3 before 1.3.0. This seems less than optimal. Also, this would presumably need to be "forced" through external process, since I don't see anything in the RPM SPEC file that would indicate this.
Are there any known techniques for handling this? A bit of Googling didn't expose any.
EDIT: By "known", I mean "tried and proven" not theoretical.
Use the right tool for the job. RPM probably isn't the right tool. Something like Liquibase would be better suited to this task.