The title is a bit misleading, as ‘programmatically’, in this case means just writing a simple SQL update query. 

For our pushes to production, we never do configuration by hand.  With Drupal, there is a lot of configuration that is stored in the db, so we script all of our configuration changes that are then run by our release process during a push to production, or to staging for our QA team to test. 

One of the updates I had to do today was to update add permissions to a role.  If you are not familiar with what permissions are or what roles are, log in to your Drupal site with an admin user and navigate to User Management –> Permissions (/admin/user/permissions).  Permissions are listed as the left most column going down.  Each of your roles are listed in the top row from left to right. 

I just created a new module and need to grant permissions to administer that module to one of our site admin roles.  To do this, I completed the following steps:

1. Query my db to get the current permissions for my role – “SELECT perm FROM permission WHERE rid = 99;”*
2. Add the following SQL update statement to a script file for running during release “UPDATE permission SET perm = ‘<text list of permissions returned in step one above>’ WHERE rid = 99′;”

* 99 is sample data.  This would be replaced with the id of the role you would like to change. 

The time has come to finally implement continuous integration (http://martinfowler.com/articles/continuousIntegration.html) more fully for the Drupal product that I am responsible for at work.  During my initial round of investigation into a tool to use for CI, I came across the following podcast, http://www.lullabot.com/podcasts/drupal-voices-52-stew-robinson-continuous-integration-deployment-economistcom, that describes the CI system used during development of the Economist web site, a Drupal site.

At this time, we have source control, a scripted build, automated tests, but they all live in silos apart from each other.  I’m installing and configuring Jenkins to link all of these processes together.

If you have done similar investigative work over the past year or so, you may be familiar with Hudson and/or Jenkins and might be wondering what the differences are.  Here are some links that should clarify things,

http://bobbickel.blogspot.com/2011/03/jenkins-vs-hudson-time-to-upgrade.html

http://stackoverflow.com/questions/4973981/how-to-choose-between-hudson-and-jenkins

Now, on to installation:

1. Running Red Hat Enterprise Linux Server release 5.5 (Tikanga), so download and install:

   sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
   sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key

    

   yum install jenkins

2. Install is successful, so start jenkins: 

   /etc/init.d/jenkins start

3. Navigate to http://localhost:8080.  Jenkins should be running

If port 8080 is not available on your machine or you need to change other Jenkins configuration parameters, my Jenkins file was located at

/etc/sysconfig/jenkins

For more advanced installation directions and more info on Jenkins, navigate to https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins

My starting configuration:

Windows 7 64-bit w/ Drupal 6 utilizing Acquia DAMP and Solr module already enabled

The Solr module has already been installed, that used to point to a remote Solr instance, but I want to point to a local instance of Solr, so here are the steps I followed:

1. Downloaded Tomcat 6 from http://tomcat.apache.org/download-60.cgi
2. Unzip the installer to C:\Program Files\Tomcat
3. Open cmd prompt and navigate to C:\Program Files
4. Try starting Tomcat using startup.bat
5. Received the following message,

Neither the JAVA_HOME nor the JRE_HOME environment variable is defined
At least one of these environment variable is needed to run this program

6. Set JAVA_HOME
7. Try starting Tomcat again using startup.bat
8. I can see the Tomcat home page when I access, http://localhost:8080/ – SUCCESS!
9. Download Solr 1.4.1 from http://mirror.its.uidaho.edu/pub/apache//lucene/solr/1.4.1/
10. Extract the Solr download to C:\Solr
11. Copy C:\Solr\apache-solr-1.4.1\dist\apache-solr-1.4.1.war to C:\Program Files\apache-tomcat-6.0.32\webapps
12. Restart Apache
13. Open C:\Program Files\apache-tomcat-6.0.32\webapps\solr\WEB-INF for editing
14. Uncomment the following section and set your solr home value accordingly, my setting is below

<env-entry>
   <env-entry-name>solr/home</env-entry-name>
   <env-entry-value>C:\Solr\apache-solr-1.4.1</env-entry-value>
   <env-entry-type>java.lang.String</env-entry-type>
</env-entry>

15. Move this section to the bottom of you web.xml file, making sure to stay inside of the </web-app> tag
16. I restarted Tomcat, but you shouldn’t need to
17. Open a browser to http://localhost:8080/solr
18. Success!

Configure my Drupal instance to be aware of my local Solr instance that is now running:

1. Navigate to the folder containing my apachesolr Drupal module
2. Copy schema.xml and solrconfig.xml to C:\Solr\apache-solr-1.4.1\conf
3. My Solr instance is being served by Tomcat on port 8080, so I need to update my Solr configuration in Drupal
4. In my Drupal site, logged in as admin, I navigated to Site configuration – Apache Solr – Settings
5. There, I set my Solr port to 8080
6. Success!

My local instance of Drupal, utilizing the Acquia DAMP installer, running on Win 7 is now also running a local instance of Solr. 

Kudos to tonyhrx and www.coldfury.us, whose blog posts I referenced during this set up process:

http://drupal.org/node/532584

http://www.coldfury.us/index.php/2010/01/installing-and-running-solr-1-4-on-windows-tomcat/

As noted above, I already had the Solr module installed and running in my Drupal environment.  For information on setting up Solr with Drupal from scratch or other general Solr information, proceed to the following link, http://drupal.org/project/apachesolr