I'm not new to web publishing, BUT I am new to publishing against a web site that is frequently used. Previously, the apps on this server were not hit very often, but we're rolling out a high demand application. So, what is the best practice for publishing to a live web server?
Is it best to wait until the middle
of the night when people won't be on
it (Yes, I can pretty much rely on
that -- it's an intranet and
therefore will have times of
non-use)
Publish when new updates are made to
the trunk (dependent on build
success of course)
If 2 is true, then that seems bad if someone is using that specific page or DLL and it gets overwritten.
...I'm sure there are lots of great places for this kind of thing, but I didn't use the right google search terms.
#Nick DeVore wrote:
If 2 is true, then that seems bad if
someone is using that specific page or
DLL and it gets overwritten.
It's not really an issue if you're using ASP.NET stack (Webforms, MVC or rolling your own) because all your aspx files get compiled and therefore not touched by webserver. /bin/ folder is completely shadowed somewhere else, so libraries inside are not used by webserver either.
IIS will wait until all requests are done (however there is some timeout though) and then will proceed with compilation (if needed) and restart of AppDomain. If only a few files have changed, there won't even be AppDomain restart. IIS will load new assemblies (or compiled aspx/asmx/ascx files) into existing AppDomain.
#Nick DeVore wrote:
Help me understand this a little bit
more. Point me to the place where this
is explained from Microsoft. Thanks!
Try google for "IIS AppDomain" keywords. I found What ASP.NET Programmers Should Know About Application Domains.
We do most of our updates in the wee small hours.
Handy hint, if this is an ASP.NET site, whatever time of the day you roll out, drop in an App_Offline.htm file with a message explaining to users that the site is down for maintenance.
Scott Guthrie has more info here:
http://weblogs.asp.net/scottgu/archive/2006/04/09/442332.aspx
Related
I have a hosted page on Microsoft Azure Web Sites (Shared) and have verified that PHP is enabled and working but I am not able to call PHP in an .html document. Is there any way to enable this?
Searched high and low on this one, sorry if it is a duplicate.
This drove me nuts too, documentation in so many areas is poor. I had the same problem last week.
Here is the fix:
On the management console of the site, under configure, scroll to Handler Mappings.
In handler mappings, in the first box, type *.html
In the second box type D:\Program Files (x86)\PHP\v5.4\php-cgi.exe
Save, then restart the instance. It will now process PHP inside HTML files.
One small thing, which I didn't realise till after as well. I instantly assumed, 5.5 is the latest and greatest, so why wouldn't I just update to 5.5 and use that engine. You can, and changing the folder structure to read 5.5 works, however the 5.5 build on Azure doesn't have PDO for SQL Server which makes connecting to a native SQL database a nightmare. So 5.4 is the best build IMO until they include that as well.
Hope this helps.
EDIT: Not sure if this is applicable to shared, I am using a small instance, but logic should be the same I would have thought.
I'm about to walk into a project that will have files (mostly PHP) behind web root. I traditionally use Dreamweaver CS4 for development. For upload I'll do a hybrid of Dreamweaver and manual FTP. As a site gets larger and more complex keeping files straight by hand becomes painful (and dangerous) very quickly.
If you are facing similar issues, what are you using? What is the best way to handle this sort of thing? It'd be great if DW was aware of the idea of placing files behind web root, but there doesn't seem to be a way to handle this elegantly.
I think that you might want to check out revision control like Subversion. It does a very good job handling your changes and deploying it to the appropriate server (staging/production). You can even find fairly inexpressive solutions that will do it all for you (meaning once you make a change and send your changes to Subversion /commit/ then Subversion will send them to your sever automatically (or you can do it manually with a click of a button). You can also use Subversion for free, but then you would have to set it up yourself.
The only problem that I see -- I dont think that Dreamweaver CS4 does not support the latest version of Subversion.
You can also check out Git
I hope that helps.
Are there any special security measures to take when deploying a Drupal site to a production server?
For instance: I can imaging that we need to remove install.php from the root directory. Are there any more actions?
Or is there maybe a module available which checks the site for "world readiness"
The status report on http://your-site/admin/reports/status will tell you if anything is not quite right.
Under the performance admin page you can turn on various caching settings, but test your site with them turned on before deploying.
There is a book by greggles for securing drupal, which may be worth a look.
Ideally you've tested your code for insecurities before deploying, but configuration can often be missed. There's a mode for analyzing your Drupal site for misconfiguration that would lead to vulnerabilities http://drupal.org/project/security_review
Security Review makes the following checks:
Safe permissions on system files
PHP in comments or nodes
Whether error reporting is on
Unsafe input formats
If private files is on and if the files directory is outside webroot
Allowed upload extensions
Admin permissions granted to untrusted users
In addition to other suggestions, remove update.php also.
I'd also (re)move /scripts from the webroot
It's a minor thing, but you could remove the text files in the root of the distribution which leak the version number. Such as CHANGELOG.txt etc.
I don't remember how safely cron.php protects itself from flood-calling. You may want to look into whether it is worth limiting that to local-only or command-line-only access.
Ensure that .inc files are processed by PHP.
all this answers make you stop thinking after your install is done - but software has a history and after installing drupal you have one more baby to watch - in drupal´s case watch VERY closely! This means you MUST subscribe to the drupal security mailing list and read all mails that are coming form there - be prepared to get many emails. It is good, that the drupal team is providing these informations fast, but it is sad that there are really too many of these mails, what might be related to drupals programming style. be prepared to get up more than once in the middle of the night to update your drupal installation because some extension developer never did understand, why input from the web must be sanitized (yes, these kind of security problems are still happening in the drupal world.)
So "hardening" means "keeping up with updates", in drupals case these come quite often. Think about this if you have many sites and want to deploy to multiple servers - automatic deploymemts will help you save a lot of time.
Here's an excellent rundown for Drupal 7: http://www.madirish.net/242.
Most of its suggestions are relevant to Drupal 6 as well.
You should also remove the Theme registry rebuilding setting.
It rebuilds your theme registry on every pageload, so it makes your site very slow.
I am currently working on a call log project. The boss wants me to use Sharepoint as a base, so I set up a virtual machine with an instance of MOSS 2007. I downloaded microsoft's call center template and installed it. I have been playing around with it for a little while now and it seems pretty simplistic. How can I modify this template (or extend it?) to suit my needs? I would also like to know how it works so if the need arises I could create my own application, so any help will be greatly appreciated here.
Thanks!
edit:
I am going to go out on a limb here and say that the aspx files I have found inside this folder:
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\
have their code-behind already compiled so there will not be much I can do in terms of seeing how the application functions this way. Am I correct here?
I developed several sharepoint features and webparts. And yes, it's a real pain in the a**.
On your Sharepoint Server look at the Directory
C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033
There should be the masterpages and CSS Stylessheet you're looking to modify.
SharePoint development can have a steep learning curve and the product seem to fight against you. This is particularly if you're used to ASP.NET and are used to all the freedom that gives. It's quite a large and sometimes complex product with its own framework and way of doing things. That why I strongly recommend doing some serious reading in conjunction with going in and trying things out with existing applications. A few points:
Support
The primary reason is because you could easily end up with an unsupported installation if you change the file system without realising the impact. This will cause serious problems if it is necessary to install service packs or upgrade to a future version. There is usually a way to deploy updated code to SharePoint without needing to go down this path.
Getting results
Another reason is that unless you know what you are doing, hacking around with little knowledge will usually result in a lot of head bashing and few results. Errors can occur that make little sense or changes that you make won't take affect.
The SharePoint way
Finally, you will seriously waste time trying to get things to work if you don't know the 'SharePoint way' of doing something. Knowing 'the way' can save you so much time and integrate with the product nicely, but if you don't know about it prepare for pain! This includes topics from custom code through to CSS and master pages, through to deployment.
I hope this hasn't put you off as it is possible to enjoy the challenge the product provides and there is some very cool stuff you can do with it. For more reading there are several questions on Stack Overflow about getting started with SharePoint development (this is just one).
My experience with MOSS development has not been pretty. IMO, it is not built for application development or custom code. There are many other portals that fit that need well. For the built in collaboration tools, it is a great tool. Going beyond that, it fights you the whole way.
At least that has been my experience.
What Alex said!
Building a call centre application should be very possible with SharePoint. Personally I'm not a fan of the Microsoft templates but they may help giving you ideas on how to build something like that.
I don't know what your app is supposed to do exactly but by building a few web parts and leveraging the oob lists and workflow features you (or a somewhat experienced SharePoint developer) should be able to create something quickly.
You should not let people with negative experiences throw you off. Like it or not, SharePoint is going to stay and once you get over the learning curve it can be very effective as an application platform.
I can see how installing SharePoint can be a pain if you've got no clue what you are doing but it's a server application; a little learning should be expected.
I've got a strong background in Linux and OSX, and just left a job where I was architecting systems based on those platforms.
Now I've got a Windows Server running IIS that has a number of different websites that it hosts. Most of them are just a bunch of HTML, JS and Images, with some ASP for some customer tools. (Each website has a different set of customer tools, or they are the same tools, but with minor code changes between them.) I'm also adding a develop web server with the same code, but the 'bleeding edge' stuff.
I need an effective way of managing changes and updates to the overall codebase (henceforth referring to both the images and the html and the asp, for all the sites). When a dev (or webmaster) checks in changes, I want it to show up automatically on the developer server, but should be manually pushed out to the live server. I'd be tempted to just make the websites SVN repositories, but I'd be concerned about the overhead of having the webdeveloper having to log into the server and trigger an SVN update via commandline/tortise (and heaven forbid, manage tags).
Ideally I'd also manage IIS profile settings between the systems, but the major need is to be able to manage the process, and expose it to our ASP developer, and our webmaster, both of which are used to just FTPing up the files to the live site.
So, any recommendations on tools (beyond some SVN hacking with BAT files + teaching the webmaster how to log into the server and do updates) or workflows that would help this out? I even considered an RPM type package (or some Windows equivalent, of course) to manage the live server, but that seems like a bit too much overhead.
First you need to decide how the webmaster knows that the latest in your SCM is ready for deployment (I assume you want some level of acceptance testing after the developer has checked in).
Depending on the above answer you should be able to define the steps to get the "approved" content built and updated on the web server, then it would be a matter of scripting this.
In the end the problem is not the commands to run, but knowing /when/ to run them, and that the last checkin from developers is not necessarily going to work 100% (even without mistakes two concurrent changes, each working, could conflict).