I have a web application deployed at client Intra net using websetup project and now i want that any change or update in the source application should be provided as a small release to the client which the client will install using the deployed application and the changes will be reflected rather than the whole application re deployed. Also the deployed patch would be roll back if it is creating problem.
I need to ask what would be the best and easy way to create a patch to fulfill my requirements discussed above?
The minimum you will have to install is: replace dlls that have changed, replace markup (apsx/ascx) that has changed. However it is rather pointless as it really doesn't save you very much in most cases. The only time I ever do it is if i only have remote access and it is slow and the site is large. It saves on the amount of data to transfer.
Related
i have a website, and i am migrating to a version 2. It's a staggered roll-out as opposed to big bang. What I intend to do is send a certain amount of traffic to the new site, and the rest the old version. I prefer not to do this on the load balancer (several reasons which I do not want to go into as it is business driven more than technical). I have a limited number of servers, so I do not wish to put the new code on dedicated servers. I also want to ensure the URL does not differ so as not to confuse the customer
The version two code is totally new and is not and will not be part of the version one codebase. The two must be isolated. Again; business driven but not negotiable.
(e.g.: he hits http://example.com/somepage, i do not want to redirect to http://new.example.com/somepage).
I am using IIS and ASP.NET MVC 4.0. I prefer a code based solution (httpmodules and putting something in the querystring for example) but cannot see how this would work.
Other than putting tonnes of iRules in the load balancer I am happy to hear any kind of solution, whether it is hardware / software / middleware.
The only way you could conceivably achieve this is via a load balancer. Otherwise, you run into the simple problem that a single domain can't be attached to multiple applications and multiple applications can't reside in the same document root. You could use a subdomain like new.example.com, but you explicitly said you don't want that. The only other alternative would be house the new app in a virtual directory of the old. Then, you could keep the domain the same, but you'd have to redirect from http://example.com/somepage to http://example.com/new/somepage. Also, the Web.config of the old application will apply to any other application housed in a virtual directory, so great pain would have to be taken to make sure there's no config bleed-through.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
So, I have a staging and live environment of Umbraco.
Our content guys make changes in Live because they need something to be visible straight away.
Now, to back this up - I'm currently copying & pasting what they've done onto our staging environment and putting into source control..
Is there a better way of doing this?
From what I know of your situation, I would recommend setting up the staging site and the production site with the same database. Unless you are using the ContentService to pull content into your templates (which you should avoid because it hits the DB), your umbraco site should only be hitting the App_Data/umbraco.config xml cache and the examine indexes in App_Data/TEMP/ExamineIndexes. This means that even though your staging and production site will be sharing the same database, changes that you make on the staging site won't show up on the production site until you log in and republish the entire site or republish the specific node.
This approach is definitely not appropriate for every scenario. For example, we have clients who won't like that the database is shared for security reasons. They want as much separation from the production site and the staging site as possible. I also wouldn't use this if the content on the site is very time sensitive. If content being accidentally published before it is ready would be very bad for your client, this might not be the best solution. We haven't experienced any trouble with the xml cache being automatically refreshed when we weren't ready, but I wouldn't trust a cache to protect sensitive information from being released early.
We have been using it and are very happy with the simplicity. There are very few moving parts, so compared to some of the other deployment methods below, this is a pretty safe way to deploy. To make things more user friendly for our clients, we rig up a button on our staging site that, when clicked, will republish the cache for that node on the production site. I hope to release this as a package and will update this answer with a link to the package when it is ready.
UPDATE
I would consider the above approach experimental. Umbraco has been putting a lot of work into load balancing scenarios in later versions of umbraco 7, and some of the work they have done may invalidate what I was talking about. Just keep that in mind if you do decide to try this out.
Here are some other tools that are interesting to think about when dealing with content deployment:
Conveyor: https://our.umbraco.org/projects/backoffice-extensions/conveyor
Courier/Umbraco Deploy: http://umbraco.com/products/more-add-ons/courier-2
Umbraco Cloud: https://umbraco.com/products/umbraco-cloud/
CMS Import: http://soetemansoftware.nl/cmsimport
uMirror: https://our.umbraco.org/projects/backoffice-extensions/umirror
uSync Content Edition: https://our.umbraco.org/projects/developer-tools/usynccontentedition
Conveyor is a young package (at least right now it is). It has a dashboard that you would be able to use to selectively export content from your production site. You can then log in to the backoffice on your staging site and import the content. I am trying this out for the first time this month. It looks very promising, so far, but I can't give you a lot of advice from experience.
Courier is meant to be the ultimate solution in content deployment. It is one of the few content deployment options that allows you to selectively deploy only the content you want to. You can right click on content and deploy from staging to production or from production to staging. Courier also tries to detect dependencies and deploy them along with your content selections. The trick with Courier is that when something goes wrong, it is a big deal. Sites can go down and depending on what went wrong, it could take a lot of time to recover them. Courier might try to deploy a document type that it detected as a dependency and accidentally ruin things. I've also found that it requires a lot of training to use properly. I haven't had a lot of success allowing non-technical folk to use Courier. If you use Courier, set up a test environment and play around for a while. Make sure you know what workflows work for you and what will break things. Courier will let you shoot yourself in the foot. Update: Umbraco has been using Courier a lot for their new Umbraco as a service. They have been finding and fixing a lot of the bugs. The 2015 versions of Courier are much more stable. If you want to use Courier, Make sure you are using the newest versions for Umbraco 7. I've recently been doing some testing on Courier version 2.50.1. Much, much better. I'd still tread carefully though. Another Update Umbraco has been depending more and more heavily on Courier. They have announced a new and reworked Courier called Umbraco Deploy. I look forward to it. Once it is released, that will be a better choice than Courier and I expect that it will function similarly.
Umbraco Cloud is a whole SaaS setup that Umbraco has been working on very heavily. They can host your Umbraco site in Azure and have a very neat UI and process for deploying not only the content and media of your site but also all of the code, document types, and data types. This is still somewhat new, and a lot of very complex sites may not be a good fit for Umbraco Cloud. Also sites that rely heavily on document type inheritance vs document type composition might have problems. As far as I can tell, Umbraco Cloud is nice for small to medium sized sites, but Umbraco does have some very very large sites hosted on Umbraco Cloud as well. Umbraco Cloud relies heavily on the new Umbraco Deploy that is based off of Courier. Chances are that if your site is having trouble with the new Courier, it will still have problems on Umbraco Cloud.
uMirror is one that I've never used, but it exists and could be useful.
uSync Content Edition is another one that I've never used. We do have experience using the regular uSync, and I've found that the author is very responsive to issues and questions.
It sounds like you are seeking something like uSync.ContentEdition, which will allow you to export the database content to disk.
You can copy the files over to staging, and then import them into the database.
Be careful though, the author himself states that it is "Experimental (but getting better)".
An alternative option would be to copy the database itself from live to staging every so often, assuming that the staging database can be overwritten. This is the approach I would take.
I don't know if this is entirely possible as a one click and done option, but what I would like is to automate our IIS MVC development setup for new developers.
Basically, what I am looking for is:
App pool creation if one is not already created (and make sure it is the correct version of .NET 4.0)
Creation of an IIS Application under the above app pool that points to the source code
Figure out if aspnet_regiis -i is needed (in the case that IIS was installed before 4.0 code was introduced)
I am not looking for a publish option as that does not point to the source code. Also, I am not looking to use the built in VS host as I am trying to use IIS to make sure everything is set up appropriately. Maybe I should not impose these limits and do not need to worry about setting up the machine as described? But if this does sound correct, currently I am looking for a way to set this up straight out of source control? Is that possible, or do I need to have an initial setup phase for all new developers?
Although I can't yet write exactly what you want, Powershell will do what you want. Here's a tutorial for creating web sites and app pools.
http://learn.iis.net/page.aspx/433/powershell-snap-in-creating-web-sites-web-applications-virtual-directories-and-application-pools/
What I would suggest is setting up the full environment on a computer then making a boot disk to return to that environment. Then run that boot disk on another computer (note: must be of the same type) which you want the environment to be on.
If it must work for different computers, and different operating systems, then the complexity of allowing for the environment to all be done at once will become greater than just doing it yourself unless you are setting up environments as frequently as daily. If that is the case, then perhaps you could make a custom installation program to do that which I am not very familiar with off the top of my head.
We have several EC2 instances behind a load balancer. Each server has several ASP.NET applications deployed to it. I'm looking for an easy, realtime, automated way to deploy new compiled code to all instances simultaneously.
I've seen solutions using source control repositories like SVN or Git, but this doesn't seem like an appropriate use of the technology for us since we're deploying compiled code to the EC2 instances - not source code.
I've also set up Dropbox to accomplish the sync. It somewhat works, but has its quirks. For instance, you need to build your directory structure around the "one root sync folder" limitation. Any other reason why we definitely should NOT use dropbox for this?
Writing a custom application using the S3 API is an option, but we'd prefer a third party solution over writing more code.
This seems like a common scenario, but I haven't found any good solutions yet.
Elastic Beanstalk seems to be the best route to go now. You simply push your web deploy project to an elastic beanstalk environment and it deploys code to all of your instances. (It manages auto scaling for you.) It also makes sure that new instances launched will have you latest code and it keeps previous versions which you can easily roll back to.
If your asp.net website needs to be auto scaled on AWS, Elastic Beanstalk is really the best end-to-end solution.
Since these are ASP.Net applications and IIS, why not use Web deploy. It's MADE for this.
http://www.iis.net/download/webdeploy
Web Deploy allows you to efficiently synchronize sites, applications or servers across your IIS 7.0 server farm by detecting differences between the source and destination content and transferring only those changes which need synchronization. The tool simplifies the synchronization process by automatically determining the configuration, content and certificates to be synchronized for a specific site. In addition to the default behavior, you still have the option to specify additional providers for the synchronization, including databases, COM objects, GAC assemblies and registry settings.
You can use Git, Mercurial or SVN to push compiled code to the servers, or to have the servers fetch code. Source control is not only for source code - it can be used for files of any type.
Also, one way around the Dropbox issue is to use multiple DropBox accounts if that's the issue. But Dropbox is a pretty easy solution because then you never need to write any code. As long as Dropbox is up, it will work.
You might want to give AppHarbor a try. We take care of managing ASP.NET application servers, loadbalancers and all the other required infrastructure, leaving you to get on with developing your application. We also provide a convenient way for you to push new versions of your app using your choice of Git, Mercurial, Subversion and TFS.
Git or mercurial will do a good job at that, subversion is bad at handling blobs.
And you get very nice control and assurance, that the code got deployed everywhere by looking at the revisions.
Seems obvious but, shared filesystem? Or push out with scp or rsync?
Why is it better to store data inside an appSettings element (or inside a custom section) of a web.config file than to store it in a class?
One argument would be that by using custom sections we don’t have to recompile code when we change data, but that’s a weak argument, especially if we’re using Web Sites, which get recompiled automatically whenever code changes!
Thank you
Because you can change it on the fly and use it without regard to class structure. Your configuration can vary from each developers machine to staging to deployment environment by changing and maintaining a single file independently of the code, and you can take advantage of *.config masking with different areas of your site.
Hard coding anything configurable is a recipe for failure and it absolutely will bite you - this is just a matter of experience, if you don't believe it then you have but to wait a little while!
By putting settings into web.config, you have them all in a centralized location.
Also when deploying a web site, you might want to precompile it once. So you won't be able to change the source afterwards (without another recompilation).
It's not really a concern of just recompiling the code, it's more about re-deploying the code. Normally, you don't deploy code to the web server, you just deploy the binaries and aspx/html files. If you hard-code your config data in the code, you'll have to rebuild and redeploy the library or application to get the change up to the server, which is a lot more work than just updating the web.config.
Putting data in the web.config file also allows the same code to be run in different environments with different environment-dependent data. This can mean running the same website code in staging with a test database connection string and in the production environment with the production database connection string. Or it could mean allowing the developers to configure the data for their own tests without changing any code, as 'annakata' mentioned.
It's just a WHOLE lot easier to manage and update the settings.
If you're using Notepad to do your development and putting the code out on the server, I would agree that there is little benefit, but if you're using Visual Studio and you build your website and publish it, you're publishing the pre-compiled dlls and not just updating text source code (.cs or .vb files) on the server. So when it comes time to update a setting at that point, anything in the web.config can be updated by simply modifying the text file, where as with other changes, you have to re-compile t whole web site and publish it.
And from experience, that becomes tricky when taking over after other developers that weren't careful about ensuring everything needed to make a web site work is in source control. I'm now stuck with a web site where we can't update huge chunks of it because of (kindly putting it) non-standard practices in the past.
Being able to update something without re-publishing the site is a huge blessing in my situation, and you never know who the poor maintenance programmer will be that takes over on your code.
Be nice to him or her. Make it easy to make simple changes.