I'm trying to divide my solution by three configurations:
Development
Testing
Release
All above will have different publishing location, so users can work with release, do their test in testing and see what is new in development release. All three versions will be build with different name postfixes and icons and installed on each user workstation.
For now I get :
Unable to install this application because an application with the
same identity is already installed. To install this application,
either modify the manifest version for this application or uninstall
the preexisting application."
I can't even install this more than once at one workstation.
So What can I do to achive this?
You can not install the same application multiple times unless you change the deployment. The easiest way to do this is by changing the assembly name. This article explains this.
As time past, I can now see that the solution was quite close, just required me to be able to specify my requirements first.
So, now I can tell that it mostly depends on number of such configurations:
if it is limited and low, i.e. live/test/dev, you can have each as separate project in solution, like AppLive, AppTest, AppDev, this requires refactoring to move everything that is common into separate projects, but it makes code and releases clearer and easier to manage.
if those configurations are unlimited, or number is high, than way to go is to load configurations from file and pick one from the pool based on custom logic.
Currently I'm using mix of both, as I want to be able to release test versions earlier than live, but also my application is used by multiple branches, and each of them has some unique styling, logos and such, so this is applied from embed xml file, and proper set is identified based on Active Directory entries.
Related
In our current dev. workflow there is main database --> DbMain. There is the process that takes the latest version of the project and automatically deploys it there and after that it triggers unit tests. As we would like to always have working version of the project in the source control each developer should be sure that he checks in the working code and all tests would be passed.
For this purpose we decided to create individual databases for each developers that has following naming convention --> DbMain_XX (where XX are the developers initial). So every developer before the check-in is suppose to publish all the changes to that database manually and run the unit tests. It is useful to setup publish config for this purpose with that is the copy of the main publish config with the only difference in the database names.
That would introduce that we will have a lot of different publish profiles in the solution that is quite a mess.
If we will not add these profiles to the source control, then .sqlproj file would still have reference to these files so the project will have reference to the not existing files.
So the actual question. Can I have single publish profile for all developers where the database name will be changed using variables? For example DbName_$(dev_initials)? Or can we have that each developer would have their own publish configs only locally and it wouldn't break the project?
UPDATE:
According to the Peter Schott comments:
I can create local publish profile, but if I don't add it to the source control, then the still be an entry in sqlproj file, but the file itself will be unavailable.
Running tests locally have at least 2 disadvantages. The first one is that everybody is supposed to install SQL Server locally. We are mainly working via virtual machines and the disk space is quite limited there. Another thing is that developers will definitely forget or not will not run tests manually every time. Sometimes they will push changes to the repo without building it or/and running tests. We would like to avoid such situations and "catch" failed build as soon as possible.
Another approach that was mentioned is to have 1 common build database. And in my case we have one (DbMain). All of developers can use it for it's needs but we will definitely catch the situation when the 2 developers will publish at the same time and that can make a lot of confusion by figuring out what's really went wrong.
A common approach to this kind of thing - not only for SSDT publish profiles but for config files in general - is to commit a generic version of the file with a name something like DbMain.publish.xml.template, and provide instructions to the developer to rename the file to DbMain.publish.xml - or whatever - and .gitignore this local copy of the file, allowing the developers to make whatever changes they want, but inherit the common settings from the .template version of the file.
Publish profiles don't need to be added to the .sqlproj to be used at deploy time, this is merely a convenience in Visual Studio to make them easier to find and edit, so you don't need to worry about broken references.
You are right in wanting to avoid multiple developers publishing to a common "build" database, this is a recipe for frustration.
Really, you want the "build" database to be published to as part of your CI process, meaning after the developers have pushed their changes.
A recent question in the Codename One discussion forum raised a question I often face when I'm waiting for a fix.
Sometimes the Codename One team indicates a fix would be coming in a couple of weeks and other times they indicate that its already fixed. Some of that opacity obviously relates to the update of the cloud servers but its unclear for me whether its just the cloud server & the plugin or is there something that I'm missing. Why isn't there a single update process?
I'd really like a more definitive answer like How does Codename One work?
for this.
Codename One is comprised of several different pieces and an update usually means we update only one of them. At a high level there are really just 2 major types of updates: libraries & servers.
We update libraries once every 3-5 weeks we update servers all the time (sometimes more than once per day sometimes ever 3-4 days).
Here is a slightly more accurate overview of what it means to update Codename One:
Plugin & related tools - the plugin itself provides the project properties, server connectivity and designer/gui builder tools. It updates as part of the native IDE update process once every 3-5 weeks. You need to explicitly accept an update prompt from the IDE in order to get this update. Bugs in the plugin itself or features for the designer/GUI builder need to go thru that process...
Build.xml - this is technically a part of the plugin update but you need to actually accept changes that we make to the build.xml to get some functionality. On occasion a new feature (e.g. the new GUI builder) needs to update the build.xml code but this will only happen if you go into project properties, click OK and accept the prompt to update the build.xml (if such an update exists).
Client libraries - these are the API's you use when writing Codename One code (typically CodenameOne.jar and related ports). We usually issue an update to those once every 3-5 weeks together with the plugin update. The plugin ships with these but they are only applied to new projects... When you send a build we implicitly update your libraries to the latest version using a separate update process, you can also use "Update Client Libs" within the Codename One preference to update these manually without sending a build.
Device libraries - when you send a build to the servers we use the latest version of the client libraries that might be newer than what you see in the client libs but might not be the latest git master. This allows us to rapidly deploy & test device fixes. This also allows you to work with the code and use newer features that weren't pushed to the Client Libraries. The process of updating the servers is a bit adhoc so there is some opacity around that, we are looking at making this more transparent.
VM & builders - The builder code and VM relate to the server side scripts that generate the code. When you have a compilation error on the servers or need an enhancement there we need to deploy it in a process similar to the device libraries deployment.
Certificate wizard update - this tool is updated in a completely separate update process despite shipping in the plugin. We had a lot of concerns about Apple changing things suddenly when initially creating this so we decided to allow this to update instantly.
Twist to the standard “SQL database change workflow best practices”
Background
ASP.NET/C# Web App
MS SQL
Environments
Production
UAT
Test
Dev
We create patch scripts (XML and sql) that are source controlled in Mercurial. We have cmd line utility that installs patches to DB (utitlity.exe install –patch) from a Release folder the build packages. Patches have meta data that helps with when patch should run and we log patches installed in a table in the target DB. All these were covered in the 3 year old question:
SQL Server database change workflow best practices
Our Problem/Twist
I think this works well for tables, views, functions and stored procedures. We struggle with application configuration data. Here are some touch points on application configurations.
New client. BA performs system study and fit analysis. Out of this comes a configuration word document of what application configurations need to be setup. Note some of these may also come in phases over time. We need to get these new configurations into the system for the developer and client UAT.
Developer works on feature request or bug fix. A new configuration change comes out of that change. The configuration needs to make it into the system for testing and promotion to UAT and up.
QA finds that the developer missed an associated configuration change. That configuration needs to make it into the system for promotion to UAT and up.
Build goes to UAT. Client performs acceptance testing but find they really want to change another unassociated configuration and have it promoted with the changes. In other words they found they want to change a business process by a configuration. The configuration needs to make it into the system for promotion to PRD.
As the client operates in PRD they may tweak application settings. These configurations need to make it into the system for future development and testing.
The general issue is making sure we are accounting for all the configurations and accidently not miss any during promotions which causes grief.
Our Attempts At A Process
a. We have had member of the QA team to write patches (xml and sql) and check those in. This requires a build to make sure those get into the package. With this approach it really just took care of item 1 above and we fell apart on the other items. The nice thing is for the items that made it into the patches it was just an install with the utility.
b. A developer threw together a Config page on the application. All the configurations could be uploaded and downloaded via XML document but it requires the app to be running. For item 1, member of QA team would manually setup configurations in the application and then would download the Config.xml file. This XML file would be used to upload configurations in other environments. We would use text diff tool to look at differences between config.xml files from different environments. This addressed item 1 and the others items but had problems. Problems were not all configurations made it into the XML document (just needs to be fixed by developer), some of the configurations didn’t have a UI in the application so you still had to manually go to the database on some, comparing the XML document with text diff was difficult at time (looked mostly due to sorting but I’m sure there are other issues), XML was not very human readable and finally the XML document did not allow for deleting existing incorrect or outdated configs.
c. Recently we went with option B, but over time for a new client we just started manually tracking configs and promoting them manually by hand (UI and DB) through the promotions. Needless to say lots of human errors.
So we have been looking at solutions. Eventually it would be great to get as much automation in as possible. I’m looking at going with the scripting approach and just focusing on process, documentation and looking at using Redgate data compare in addition to what we had been doing with compare on config.xml. With Redgate we have to create views though and there is no way to create update scripts from that approach except to manually update the scripts. It does at least allow a comparison without the app running. I’m also looking at pulling out the configs from our normal patches and making it a system independent of the build (utility.exe –patch –config). When I say focus on process it will be things like if we compare and find a config change either reported by client or not, we still script it, just means we have to have a process in place to quickly revalidate config install before promoting to the next level. As for documentation looking at making the original QA document a living document instead of just an upfront document. The goal is to try and enhance clarity and reduce missing configurations during promotion. Unfortunately it doesn’t improve speed of delivery.
Does anyone have any recommendations or best practices to pass along. Thanks.
Can I ask exactly what you mean by application configuration. I'm interpreting that as both:
Config files in the web application
Static reference data inside the database
Full disclosure I work for Red Gate. You might be interested in taking a look at Deployment Manager, it's a deployment tool that deploys applications, databases and configuration. It's free for up to 5 projects and target servers.
The approach it uses is to package application code and the database state into packages. These packages can be deployed into dev, test, staging and production environments. The same package is deployed to each environment.
Any application configuration that needs to change between environments is handled in one of the ways below:
Variable substitution in web.config. The tool allows you to specify override values for variables in these files, and set these per environment/server
Substituting the web.config file per environment.
Custom powershell scripts that are run pre/post deploy. You could use these to execute custom SQL based on the environment or server.
Static data within the database, using SQL Source Control's static
data feature. I've written a blog post about how to supply
different sets of static data to different environments/customers.
This allows you to source control the application configurations and deploy them to different environments.
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
Is there any utility that will copy the "official" build of a windows forms app from a central network share and launch it (from a client desktop)? I want to make sure users get the latest version when I update the binaries on the central network share.
ClickOnce is user un-friendly so I'm looking for something else...
Is it possible you could revise your question to describe what it is you find unfriendly about ClickOnce? In my office we have found ClickOnce to be the most efficient and user-friendly way of updating and distributing applications desktop business apps that we have ever had. I'm wondering if the best way to resolve your question might be to address the issues you have with ClickOnce, rather than integrating/rolling another solution.
I've done this before by the following method:
1 - Keep the "official" build at a specific network location
2 - User launches program from their local machine
3 - At launch, program compares its' own file version # to the one on the server.
4 - If the two versions are different, copy the new version down from the server and relaunch.
Pretty simple, and it works as long as you are in an intranet environment.
Step 4 is the only tricky part. You can't replace a file while it's in use, so you have to either
1 - first rename the current (in-use) file and then copy down the new one. Since you will be updating many times, you'll also want to delete any existing renamed copies that are hanging around.
or
2 - Have the user launch a "helper" application that does the version check, updates if necessary, and then launches the real app. Of course then you have to deal with updating the helper app.
We have a tool that would do that, which has been in use before there was such a thing as Windows Update (or any other update.)
The problem with any sort of update of this fashion is the security level of the user. Many times you need to be administrator to perform certain functions.
Our solution is two part/one executable: 1. a service mode that runs local system or admin to perform such operations. 2. an executable which can be called by an app to fetch via UNC, HTTP, FTP the updates for an application and apply them.
The basic process is this:
1. Application checks its version number; we use a central database to list all applications and their version numbers.
2. If the application is a minor revision we give the user an opt out on the install; if it is a major revision we require an install.
3. Once the update is confirmed, we call the updater executable which in concert with its service mode product, retrieves the updates, installs them, and relaunches the application.
If you are interested, go to the website listed in my profile and send us a support request address to me and I will give you more details and the codebase if desired.
Check out this one:
.NET Client Applications: .NET Application Updater Component
It is a white paper which discuses in detail on what it takes to make an application auto-updatable.