Visualising three years of development

About two and a half years ago I made a visualisation of the work on SYND so far. Much has happened since then, and with the three-year-anniversary of the first commits to the SYND repos rapidly approaching, I felt it was time to revisit gource and do another loop through the commit history. Presenting the three-year-mark of YDD development:

Much have changed since the previous visualisation, the biggest of the changes of course the creation of the two sub-branches of the project, SYND and FYND. It’s easy to see how much the project has expanded in scope and complexity since we started, something that would have happened even without the forking of the project.

Switching Distros on a Running Site

As Mårten explained in an earlier post we decided to redo our installation profile into a more diversified model with a common core set of modules and with a differentiated set of modules for every site that will use the common core.

Splitting the previous Yle – profile that we used as a base for our installation from the beginning was easy enough. Just create two new installation profiles – Syndprofile and Fyndprofile that used most parts of the earlier Yleprofile and the parts that were specific for the two installations into their own sets of repositories, ie synd_modules and fynd_modules and so on. Starting development on the fynd-platform was also very successful and has since launced two successful projects: Kuningaskuluttaja and MOT.

However, on the svenska.yle.fi – platform, the change posed a lot of challenges to overcome, since we had to change installation profiles on a running site. And since a lot of the path settings to modules and themes are set in the database at installation time a lot of file paths would have to be changed. So when we first tried the easiest approach, just replacing the profiles/yleprofile installation folder with a profile/syndprofile we were left with a severely broken site, that couldn’t find any modules or themes, no matter how many times you tried to clear the cache. So it became clear that we had to do the changes directly into the production database.

So what we did was to dump the database into an sql file and doing a search and replace on every occurence of yleprofile to the new synprofile. We opted to slightly change the name to synprofile since there are a lot of serialized data that contains the path in the database as well.

We have around 500 000 nodes in our database at the moment, and a pretty large index, but using sed to do the search and replace the operation only took a few minutes to do, even though the sql file itself is getting close to 5 Gigabytes in size.

$ sed ‘s/yleprofile/synprofile/g’ < svenskaylefi.sql > svenskaylefi_synprofile.sql

This, however, was not enough in our case. We also had a couple of modules and our own theme settings and features that was not going to be used in the other distributions so we had to manually change the location of these. Fortunately most of the file path settings are stored in just a few tables.

system
registry and
registry_file

The paths are also stored in the cache tables so it is advisable to truncate them at the same time, especially

cache
cache_bootstrap and
cache_path

It took a few tries to get every step in this workflow to work out without problems, but when we finally figured out how to do it the migration process went pretty smoothly. Just one final hurdle gave us a bit of cold sweat when the site didn’t even bootstrap even though the migration process had otherwise gone smoothly. But, a manual flush of the memcache server solved that too.

 

Versionshantering till nytta och nöje

Inget utvecklingsprojekt borde vara utan ett system för versionskontroll, inte ens om man är den enda som jobbar på sitt projekt. Och när man är många som jobbar med samma projekt så är det idag nästan omöjligt att göra det på ett vettigt sätt utan att stöda sig på någon form versionering.

Vad får man då för besväret av att vara tvungen att börja bokföra vad och hur man lägger in kod i sitt projekt? Jo, inte minst en möjlighet till att gå tillbaka och ångra saker som gått sönder eller som någon av misstag skrivit över. Eftersom varje ändring i varje fil sparas så kan man enkelt gå tillbaka i filens historia och kolla vad som ändrat, när något ändrat och vem som gått och ändrat. Och när det uppenbarar sig nya och oväntade buggar i sajten så är det en lättare att felsöka den genom att kolla upp vilka ändringar som gjorts i historiken.

När vi började med projektet i oktober så stod valet mellan Subversion, som vi alla kände från förr och det nyare och modernare Git som för de flesta av oss var ett system vi kände till, men som knappt någon av oss hade använt från tidigare. Git har ändå så pass många fördelar framom Subversion att vi valde att använda det. Den främsta fördelen som Git har är att det är ett decentraliserat system, dvs att man inte är lika beroende av en central server för alla versionerna, utan hela projektets alla filers alla versioner finns hela tiden tillgängligt också på din egna hårddisk, och på en centralt ställe som alla i teamet har tillgång till, det som i git kallas origin-repositoriet. Den andra stora fördelen med Git är att det är enklare att jobba på flera utvecklingsspår (såkallade branches) samtidigt.

En liten del av projektets git-logg.

Fram tills vi publicerade den slutna betan så klarade vi oss ändå bra med en huvudsaklig master-branch som vi alla sparade våra ändringar till. Nu, i och med att vi har en sajt som i det närmaste kan räknas att vara i produktion så behöver ändå lite mer kontroll över vad som läggs ut på produktionsservern. För att göra det lättare att ha koll på just det så använder vi nu två huvudsakliga branchar; master-branchen och dev-branchen. Nu sker alltså det huvusakliga utvecklingsarbetet i dev-branchen och endast färdiga och testade helheter ska sparas in i master-branchen. På det sättet så försöker vi minimera att det smyger in fel som kan ta ner sajten eller orsakar annan otrivsel för redaktörer och besökare.

Det är ändå inte helt problemfritt att jobba med många branches, framförallt blir det väldigt viktigt att se till att man är i den rätta branchen då man hämtar in och sparar ny kod, de första dagarna med flera branches gick åt att lära sig att hålla reda på var man var, och vart man höll på att spara sitt material, men redan nu känns det naturligt och enkelt att jobba med flera utvecklingsspår.

En historik som sträcker sig tillbaka till projektets början ger också fina möjligheter att visualisera hur projektet vuxit sig fram från starten i oktober fram tills idag:

Om betydelsen av communities

Paneldebatt på DrupalCamp

En av de stora fördelarna med att jobba med att utveckla på en open source-plattform som Drupal är att det alltid finns en massa andra som håller på och jobbar med precis samma saker. Och några gånger per år så samlas en del av dem på ett och samma ställe för att dels ta del av vad som är nytt och intressant inom Drupal-communityn men också för att träffas, mingla och skapa nya kontakter. Stora internationella Drupal-kongresser ordnas två gånger per år, en i USA och en i Europa, dit de största namnen inom Drupal-världen samlas, men minst lika viktiga är de mindre Drupal-campen som är mer regionala, och samtidigt mer intima. Man kan säga att om DrupalCon är de stora kommersiella aktörernas spelplan så är camparna de platser där man är mer jordnära och kanske mer inriktade på praktiska frågor kring Drupal och hur plattformen kommer att utvecklas.

”Drupal is standing on the shoulders of giants, but the giants have sore shoulders”

-Jeff Burnz

Jeff Burnz, som är ledare för design-intiativet för Drupal 8 höll inledningstalet, och kom med en påminnelse om att alla kan och gärna ska delta i utvecklingen av Drupal, man behöver inte vara någon expert på kodande för att kunna hjälpa till. Redan så små saker som att vara aktiv med att ställa frågor, att kommentera inlägg och att rapportera buggar hjälper till att göra Drupal till en bättre produkt.  Och det är inte bara på de stora sajternas villkor som plattformen ska utvecklas, också de tusentals mindre sajterna som drivs på Drupal behöver kunna säga sitt, och vidareutvecklingen av Drupal kan inte bara hänga på Drupal-rockstjärnornas axlar, också om det skulle kännas lättare för de flesta av användarna om det var så. Den viktigaste saken att komma ihåg är ändå att inget bidrag är för litet, och att alla verkligen får vara med och utveckla. Där ligger kärnan i hela open source-filosofin.

Av alla, för alla.