Add build script to scripts directory

[patcon]

Instead of just doc'ing in readme, we should have a simple build script version-controlled

[sylus]

I am with you on this will likely bring in CTA's work for this.

[patcon]

"CTA"?

[sylus]

Haha yeah I should stop using acronyms :P A shell script that @joejoseph00 built ^_^

[joejoseph00]

CTA is us, aka OTC.

[RobJohnston]

So when will we see some code? I think there's a similar, but defunct, effort here: https://github.com/diversen/densite. Might be worth pilfering for some ideas.

[joejoseph00]

Hi Rob, what are you looking for?

This script: http://wet.7pro.ca/sites/wet.7pro.ca/files/wet_drush_sh.txt makes a build in your userdir ~/username/drupalfolder so that you can easily create multiple wetboew installations for testing and dev purposes quickly. permissions are adjusted for dev purposes, this works well for integration with NetBeans and remote debugging because it's less complicated dealing with permissions in a dev context using the userdir

the script does this and then tells you where to access your site: ex: http://hostname/~/username/drupalfolder

Rewrite options are automatically configured, as are permissions so it's pretty much run it and go provided your apache config has userdir enabled.

TODO: I'm going to make this script perform updates TODO: make this script verify some basic apache settings like userdir TODO: will work on some suggestions patcon gave me for improving the script code/logic

[RobJohnston]

Hi @joejoseph00. I was going to start writing a script of some sort to make some tasks easier for me at work, to make it easier for one of the other developers to get a dev environment going quickly, and maybe to move a production site back to testing quickly via a script for those times when disaster strikes.

As you know from out other conversations here, the work environment I've got is using sqlsrv and not mysql. The logical assumption after that is that it's a Windows environment, so the bash script wasn't where I was going to start. Finally, we don't even use Apache but IIS6. I can tweak your script for my test system at home using postGres, but at work I'll need something else.

With all that difference from the *nix + Apache + mySql world, my script will be something that brings in the sqlsrv module, applies various patches for working with sqlsrv, applies Windows permissions to files, and configures IIS -- as much as I can do via a script anyways. I was hoping to get the logic of the steps from existing code and then adding the old switch-case statements for our particular environment.

So with all that being said, I'm leaning towards writing something using Drush, like the densite link I gave above, since that is cross-platform (there is a Windows installer). I think I'll take a closer look at that over the next few days. Any thoughts about basing your script on Drush?

[joejoseph00]

Hmm, with dos scripting you should be able to do pretty much the same thing, however I'm not sure how much you can do with mssqlserver from script without building an actual executable using the api's. I have automated things with mssqlserver using the SQLDMO dll libraries and COM wrappers for C#. I imagine there's newer versions of SQLDMO but I used to include the SQLDMO dll in a C# program, automate it like that, and you can call dos scripts from a C# program, but collaboration with microsoft tools means that everyone that wants to collaborate has to shell out $ and or install a bunch of programs and eventually you end up having to get the whole msdn and not really need all of it but have to pay for all of it to get the pieces from here and there to do what you need to do. SQLDMO gives you pretty much full control of a mssqlserver instance, it's kind of like enterprise manager for programmers. (they enterprise manager something different now, but it's still got the same functions)

microsoft has probably a newer version of SQLDMO that you can use, probably some dll somewhere in the mssqlserver installation.

That being said, I don't have msdn. We can get as good or better performance out of mysql and we like the plethora of mysql administration tools.that give you pretty much all the goodies a dba could ask for. mssqlserver is a cadilac though, but ya, we're mainly an oracle shop here and we have Linux VM's available so I don't get to do much on mssqlserver anymore.

As far as Drush, I'll have to use that to configure my script to do wetboew updates.

[RobJohnston]

When I overthrow the government every stain of Bill Gates' infected, corroding fingers will be sponged and purged and, if need be, blasted from the GoC network. Until then, we all gotta work with what we have and the decision to go with Windows/sqlsrv/IIS was made much higher on the pay scale then where I sit.

Since we're all developers, "SQL Server Client Utilities" is installed on everyone's machine, so I don't expect a problem with SQL-DMO (I even think that it's a redistributable set of DLLs), but I wasn't too interested in doing any database work that couldn't be accomplished with the osql utility from the command line.

I'll kludge something together for me but would rather have a collaborative effort that works for everyone.

[mgifford]

@RobJohnston Can you share what you kludged together for the Windows Server?

[RobJohnston]

Didn't do it. My contract keeps ending and I think that I'll be done with Drupal, but then I get called back on an extension (I think I'm on my 5th now). I just got back about 3 weeks ago and I'm done in another 5 weeks... no time for something that is so seldom done. If I have to do a new install at work on Windows then I use the Mac sitting beside me and run a script I call "getwet":

mkdir wet-boew
cd wet-boew
git clone https://github.com/wet-boew/wet-boew-drupal.git tmp/wet-boew-drupal;
../drush/drush make --prepare-install --no-gitinfofile --working-copy tmp/wet-boew-drupal/build-wetkit.make tmp/drupal_wet-boew -v --yes
rm -Rf tmp/wet-boew-drupal
cd tmp
tar -cf drupal_wet-boew.tar drupal_wet-boew
cp drupal_wet-boew.tar ../../
cd ../..
rm -Rf wet-boew
rm -Rf tmp

Then I just copy the tar file to a Windows box. The instructions as listed on the home page don't work well for me on Windows. Sometimes I even use the Mac to shell into a Linux box at home where I don't have an admin restricting me and then copy that tar file to Windows... the OS triathlon!

P.S. I think I edited that after the last time I used it, so should test again.

[mgifford]

How frustrating. I was so hoping that there would be a reasonable git client for Windows now. To have to jump through all that just to FTP it up to Windows is just plain crazy.

Not that I know any other way to do it, but wow. Why not just host it on Linux? Furthermore, from a security point of view, how do you know that the code on the Windows server hasn't been compromised? With Linux you'd just compare it with the master git repository, but if you've just pushed up the tarball...

Anyways, this is very useful information as we move to setting up Drupal in a Windows server environment.

[RobJohnston]

Well, I don't FTP the tarball to my workstation... I use a USB drive or SCP :-)

Git works well with Windows (I've used both the bash and GUI version), Drush has some problems on Windows (as can be seen in other issues here) but getting them both working together hasn't worked for a while and fixing it is not worth the effort right now.

We don't use Linux or Apache or postgres/mysql because I'm not in charge of infrastructure. Just for us, we'd be able to tell if code on the live site had changed by comparing it to the staging site on our side of the firewall (which we can compare to the testing site, which we can compare to the maintenance site, which some of us can compare to our local development site). Local boxes are the only ones that have Internet access anyways, so no repository comparison can be done on the others.

[mgifford]

So you've got actual access to the boxes. Been ages since I could go and plug a USB key into anything. It's just such a hassle to maintain redundant everything and have proper failovers.

Good update on Drush/Windows.

What's the comparison tool you're using? The server has Internet access.

Strange all of these restrictions. The idea of working on a website without having direct access to the Internet all the time is something I've never had to do.

[RobJohnston]

The comparison tool is Beyond Compare, but others do the same. We have physical access to local workstations (which have internet access and lets us see if updates are available) and network shares/remote desktops to the other machines. Content authors work on staging and then deploy over the firewall. Speaking of security, nobody has accounts on the live server and the web.config (like .htaccess) has rules which prevent access from the Internet to the login page and rest server. P.S. We're off topic on a closed issue. Dig around and I think you'll find my gmail address.

[sylus]

Closing this issue.