Recently we reviewed our current approach for automated regression testing for one of our products here at Comic Relief. In this post I will discuss about our new approach for automated regression testing for Giving pages project.
For those who aren’t familiar with the concept of Pattern-Lab (or a Pattern Library), it’s essentially a living style guide; a common tool in modern web development. At their most basic, they are continuously updated documents that help documenting common design styles for web components, bringing together the intended look & feel with the images and codes to build them.
I started to look into this idea around a year and half ago because I found that each time a new project started, I needed to redo much of the same styling work. Even worse, when the main project was still in development, it was hard to keep an eye on the minor changes that affected other projects, so they would quickly get out of sync with each other. There wasn’t a centralised place to store reusable components. Unfortunately, my initial attempt to push a “shared Pattern-lab” idea didn’t work too well because we had difficulties integrating with various tools and workflows across teams.
Drupal 8 at Comic Relief
Over the last year a key objective for the Technology team at Comic Relief has been to build products not websites. Tech Lead, Peter Vanhee, explained in a previous blog post how we’re using Drupal 8 to create a reusable platform product for building campaign websites. Since then the team have been working to deliver another website using the platform codebase and also preparing to open-source the codebase.
We have now opened up this codebase – you can find it here.
10 years ago (at the end of 2006), Drush appeared to make it easy for Drupal developers to do some common tasks, it wasn’t immediately popular as it was a Command-LIne tool and a lot of people didn’t appreciate the idea, but year after year it’s popularity grew as did its functionality.
By the time Drupal 7 came out it was unimaginable for most developers to build a site without Drush because of the incredible boost they got in their development process and the option of generating a site from a makefile and avoiding the need to add in their project contrib code or risk of people hacking the behaviour of this module and unfortunately this was a common practice.
But Drush with the makefile wasn’t good enough, if they update some module the makefile won’t show any update, sometimes some releases breaks other modules and it wasn’t a clear way to say “I need up to this version of that module”, indeed the whole update process itself wasn’t very automated at all, and it was only useful for download a specific version of a module and with his dependencies (it gets the latest version of them without check if they are compatible)
I talked about our journey of building a product to power all our editorial websites at Comic Relief (see my previous blog post), and focused on three topics: editor experience, automation & streamlining, and using decoupled services.
Check out the video of my presentation (audio+slides),
In the past we used a Drupal 7 multi-site powering at least 3 different sites at the same time with all our business logic bundled inside of various massive custom modules shared along all the sites and some of them with dependencies of external modules (like Message Broker) and each site was using a different version of these modules.
We were restricted to deploying the work of a large team every one or two weeks. When something broke because of the number of changes we’d just deployed together with everything, we were unable to immediately know the source of the issue and sometimes we had to wait till the next scheduled deployment in order to fix the problem.
We changed a few of the services that support our apps for Red Nose Day giving pages before the big day this year.
One of the more interesting processes was finding a good solution for all our caches and session data. In many cases, we found a Redis service worked well with our Cloud Foundry apps, especially when data has to be shared.
The move to Redis wasn’t entirely seamless, but it worked well for us on the night, and has taught us lots. This is a quick summary of what we’ve found so far.
‘A lack of women in technology jobs is not just a problem for women, it’s a problem for the whole sector.’
That’s the conclusion reached by the Tech Partnership and Founders 4 Schools, who recently published research into diversity in the sector. Alarmingly, this research also found that only 17% of technology staff are female. Worse still, fewer than 10% of these women are in leadership positions.
As part of our objectives in 2016, we set out to solve a recurring problem at Comic Relief: how can we build an engaging, fast and secure fundraising campaign website – the likes of rednoseday.com and sportrelief.com – in a couple of months? How can we make sure that editors are able to create compelling landing pages that reach their different audiences?
One of the goals we set ourselves for 2016 was the re-architecture of our Fundraising & registrations platform and moving to micro services. The team has been busy on that this year and the work will continue well into 2017 too. Here is a small rundown of our journey so far.