I have a module in production that I would like to upgrade with out losing any data. I can't find any documentation on how to write an upgrade package though. My change involves upgrading my table.
That depends on how you originally developed the module.
If you by chance used my module templates, it is super easy.
Create a new SQL script (.sqldataprovider), this script should be only the CHANGES not recreating the same table. So if you added a column, the script should check if that column exists already, if not, add it to the table. If adding procedures, it should check if the proc exists, drop the original one and create it again (or you could use alter)
Include a reference to that and the version number for that in your .DNN manifest file.
Change your Version number in assemblyinfo.cs
Change your version number in the DNN file for the module's version.
Package the module in "release" mode again.
If not, you'll have to do all the above steps, but step #5 would be where you have to manually package the module into a ZIP file.
Related
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
In creating a package with Data Types and Items, what are the best practices to follow for subsequently upgrading a package in order to retain the data that's created on the site while adding a change to the associated Type?
Should the package name remain the same or should it include version information to retain uniqueness by version? The version number of the package does not seem to enforce any type of upgrade policies.
Currently during development the package is uninstalled then the newer package is subsequently installed however after the package reaches production I believe this type of upgrade workflow will not be sufficient without affecting the associated data.
As long as you increase the package-version but keep its unique GUID and Name, you're able to install the same package again, forcing C1 to overwrite the existing files, configuration etc.
This has a few caveats though, mainly if you need to delete some old files or configuration entries during installation, since that's what you normally do during un-installation. But you can still do it, writing your own installaton-steps code.
It is classes inheriting from some core base package-classes that you can invoke during installation. It can contain logic like checking if certain other packages are installed, do custom special logic, or clean up from earlier upgrades.
But yeah, long story short, as long as the version number increases you can "upgrade" a package, by installing the newer version, while the older one is still installed.
I'm using TeamCity 6.5.4 and I need to have 3 build configurations for the same deployment package. I'd like to persist the version number across all three build configurations and be able to use that number to version the assembly, tag vcs, version the nuspec file, etc.
Here are the configurations and desired version numbers:
Configuration | Version
-------------------|---------
CI/Nightly Build | 1.1.*
Minor Release | 1.*.0
Major Release | *.0.0
It seems that TeamCity uses a separate build incrementer for each configuration. This means every time we have a major or minor release, I'd have to manually update the persisted values (1) in all of the subsequent configurations. I'm a programmer and I'm lazy. I want a single button to do everything for me.
I've seen examples of persisting the build number through build steps of a configuration with dependent snapshots, but that only works in the same configuration.
The Autoincrementer plugin bumps up the number every time you reference the ID. This is fine for the changing numbers (*), but not so good for referencing the persisted values (1).
Is there a way for TeamCity, either natively or via plugin, to allow me to read and write that version to a file or variable that can be persisted across build configurations?
You can reference the build number of the dependent ( artifact / snapshot) configuration using dep.btx.build.number where btx is the bt id of the latter. Once you have the build number, pass the build number to your script running in the configuration, parse the build number in the script and send service messages from the script to Teamcity to set the build number in the way you want. Do this parsing and setting number as the first step in your script / first step in the build steps.
Thanks for the suggestions. I opted to write a set of custom targets to use with my MSBuild script which maintains assembly metadata in a remote xml "manifest" file. When a new TeamCity project is created, my build script calls an Init target which creates a new manifest file from an unpopulated template.
<Copy SourceFiles="#(ManifestTemplate)" DestinationFiles="#(ManifestTemplate->'$(ManifestFile)')" Condition="!Exists('$(ManifestFile)')" />
I'm using the MSBuild Extentions pack to read attributes like version information from the manifest file.
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="ReadElementText" File="$(ManifestFile)" XPath="/Package/Version/Major">
<Output PropertyName="PackageVersionMajor" TaskParameter="Value"/>
</MSBuild.ExtensionPack.Xml.XmlFile>
I have my TeamCity build configurations separated to CI, Test, Minor Release, and Major Release with different events triggering each. From the corresponding target in my project build script, I add a new target to DependsOnTargets attribute to call the custom target to update the appropriate version number and save it to the manifest file.
<Target Name="Test" DependsOnTargets="IntializeBuildProject;Build-UpdateVersion-Build">
<MSBuild Projects="$(SolutionFile)" Targets="Rebuild" Properties="Configuration=$(Configuration)" />
<TeamCitySetBuildNumber BuildNumber="$(PackageVersion)" />
The code in the custom target to handle the version update:
<MSBuild.ExtensionPack.Science.Maths TaskAction="Add" Numbers="$(PackageVersionBuild);1">
<Output PropertyName="PackageVersionBuild" TaskParameter="Result"/>
</MSBuild.ExtensionPack.Science.Maths>
<MSBuild.ExtensionPack.Xml.XmlFile TaskAction="UpdateElement" File="$(ManifestFile)" XPath="/Package/Version/Build" InnerText="$(PackageVersionBuild)"/>
This file handles persistence of the version and other metadata thus ignoring the TeamCity build number. Since the XML metadata file is centralized, I can use the values to populate my Nuspec, AssemblyInfo, and WiX Installer metadata as well as pass the version and other pertinent information back to TeamCity through service messages.
I added a simple MVC web interface to allow my team to edit the file contents remotely if package details change. Now we have one single place to update things like Copyright information and any other metadata for a given build project. I can also give non-dev folks access to the MVC site to update branding information without allowing them access to my TeamCity build configurations.
With the exception of the service messages used to relay version to TeamCity, there's very little here that's coupled with TeamCity. I like having the functionality in custom targets and build scripts removed from TeamCity on the off chance we move to another build management solution. For that reason, I don't envision taking time to build a TeamCity plugin, but there could be a blog series coming soon.
I'll be happy to provide more code and further explanation to anyone interested.
Yes, you can create a plugin to do this easy. You can take my auto increment build number ( across configurations ) plugin and modify it to fit your need. The build number will be saved in a text file that is configurable from the admin screen in TeamCity.
http://github.com/ornatwork/tc_plugins/tree/master/unique
You can hit me up for input how to change it if you need.
Last week i read about liquibase quick start and all the related tutorials but i feel like i don't get the whole drift about using it for consecutive change in the database and i have some questions still opened.
i'm developing an application in netbeans using maven with 3 modules: dbunit module, service module and the webapp module.As you might have guessed dbunit does the database stuffs, the service is on top of it and the webapp uses the services.so the parent pom has the declaration of all groupids, artifactids and versions for all jars and plugins.
I manage to generate the changelog file from command line since the db is already existing and supposing i set up everything correctly using liquibase maven plugin :
question 1 : What will the liquibase goal be since right now i'm doing any database change right now?
Question 2 : If i want to add for example a new table to the database, will i add the this new changeSet to the same changelog file or i have to create a new changelog.xml file?
Question 3 : I believe when the dbunit runs it will run the changeset but is that necessary to add the plugin to th webapp module too (maybe to run the liquibase goal before deployment with cargo plugin) or the dbunit will take care of that?
Question 4 : What exactly subversion helps with keep the states of the changelog (assuming there is only one changelog refere to question 2)
thanks for reading this and for you help.
See http://www.liquibase.org/documentation/maven
so you should bind your liquibase execution to a phase like
<phase>process-resources</phase>
But i use a spring executor, too. So everytime my app starts up, it starts a liquibase executor to execute missing changelogs in the database. It is nice, because when you are ready with your work and your tests, liquibase has updated your dev database but not your production database. But when you install your war and start your webapp, liquibase handles it automatically to bring your database to current state. So you don't have to remember doing some extra stuff before deploying your new version.
Keep your changelog.xml with includes to changelog files like this
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-1.9.xsd">
when you want a new table, add a changelog-0002.xml file and reference it in your master changelog.xml
see answer 1. I would put in your webapp module too.
You should have many changelog files. so this question is not applicable.