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).
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.
Our application commonly used an ActiveX control to download and install our client on IE (XP and prior), however as our user base has drifted towards more Vista boxes with "Protected Mode" on, we are required to investigate.
So going forward, is it worth the headache of trying to use the protected mode API? Is this going to result in a deluge of dialog boxes and admin rights to do the things our app needs to do (write to some local file places, access some other applications, etc)?
I'm half bent on just adding a non-browser based installer app that will do the dirty work of downloading and installing the client, if need be... this would only need to be installed once and in large corporate structures it could be pushed out by IT.
Are there some other ideas I'm missing?
This client, is it a desktop application and not some software that runs inside the browser? In that case, please just supply a regular download installer application. My personal experience with browser-hosted installers is that they are just confusing and the few I have seen seemed to be poorly coded in some way.
If you use an MSI based installer I'm sure lots of Windows domain administrators will love you too, as Microsoft has tools to deploy MSI based installations onto large sets of machines remotely.
Its far better to do this right than put it off any longer. Vista is Microsoft's way of saying they aren't letting people get away with ignoring security issues any more and encouraging people to update their code.
I'm sure other users here will be able to point you are some MSDN best practices about writing ActiveX controls.
Have you checked out Microsoft's ClickOnce Deployment?
If I remember correctly you can embed a manifests which would help with dealing with protected modes automatically, saving you those headaches with the APIs.
I believe ClickOnce is geared for the same thing your ActiveX installer was designed to do.
Since you say your IT dept could push this out, I assume you could use this kind of technology as well.
Even though you might not be writing applications on the .NET CLR, you can use Visual Studio to generate those manifest and installers for you.
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