Category → centos
Giving Devs a Dev platform
It's a typical situation, the developers develop on their own boxen, they only start to integrate their code on on the production platform 3 hours before the deadline. And then the problems start, the typical "But it works on my system" , "its your problem now" is something nobody really likes to hear .
So how do you tackle this problem ? As Christian already mentions Talking is the first step of the solution,
But one of the most satisfying approaches to solve this problem is to provide your development teams with a standard platform that you support, and a platform they can play with , if you can't provide them with a fully defined platform, give them a set of guide lines on what they can expect. Things like library versions, database types , memory availability and storage availability are key components of such guidelines.
My platform of choice for this kind of projects today is to for an Enterprise Level distro, a distro that stays stable for a longer period, not one that is bleeding edge and changes every other week. So a CentOS or a Debian based distro is probably going to be the platform of choice. But a stable standard platform also means that all the latest nice features a developer wants to have from the bleeding edge libraries he is using aren't going to be available .
Sometimes your devs really need those features, sometimes its just a nice to have. On the other hand you as an ops guy don't want to be packaging and configurating every single tool they dream off. As usual in a Devops environment the key can be found in communication ... Talking with the devs will teach you what features they really need and how they might solve things in a different, more standardized way
We've learned that by giving them a default platform and keeping an open conversation helps, some developers take longer to understand the process others jump in right away .. but in the long term you really need to talk to your devs as soon as possible when they think of implementing a new project that has to run on your platorms.
Lets you sleep at night ..
Technorati Tags: 
Trackback URL for this post:
Packaging Drupal Modules or not ?
So John wrote down his experiences on deploying Drupal sites with Puppet .
It's not a secret that I've been thinking about similar stuff and how I could get to the best possible setup.
John starts of with using Puppet to download Drush... while I want to use rpm for that ...
I want my core infrastructure to be fully packaged... not downloaded and untarred. I want to be able to reproduce my platform in a couple of months , with the exact same versions I`m using now .. not with the version that happens to be on ftp.drupal.org at that point in time, or with ftp.drupal.org being down.
Now the next question off course is what's the core infrastructure.
Where does the infrastructure end and does the application start. There's little discussion about having a puppet created vhost , an apache conf.d file, a matching .htaccess file if wanted , and the appropriate settings.php for a multisite drupal config.
There's also little doubt to me on using drush to run the updates, manage the drupal site etc . Reading John's article made me think some further about what and when I want things packaged.
John's post lead to a discussion on #infra-talk on getting all drupal modules packaged for Centos with Karan and some others
In a development environment I probably want to have periodic drush updates getting the latest modules from the interwebs and potentially breaking my devs code. But making sure that when you put a site in production it will be on a fairly up to date platform, and not on the platform you started developing on 24 months ago.
In a production environment however you only want tested updates of your modules as indeed they will break code.
It's probably going to be a mix and match setup having a local rpm/deb repo with packaged modules that have been tested and validated in your setup and using drush to enable or configure them for that production setup.
But also having a CI environment wher Drush will get the new modules from the interwebs when needed. and package them for you.
To me that sounds beter than getting all the available Drupal modules and packaging them, even automated, and preparing a repository of those modules of which only a small percentage will actually be used by people.
But I need to think about it some more :)