Rebuilding the Cheppers website with Drupal 8: Brave New World
Why Are We Doing This? Are We Crazy? Have we made the right decision? Let’s look back over the process. We assembled the Cheppers team to discuss the pros and cons of using Drupal 8 (D8) over Drupal 7 (D7). What began as a perfectly calm discussion quickly devolved into a heated debate. Those on the D8 side wanted to explore the unknown territory of D8, while those on the D7 side argued that using D8 at this point is far too risky. What follows is the summary of this debate, edited for civility.
Pros
- We need to get a significant amount of experience with D8 before we take on the first D8 client project and this is a great opportunity for that.
- Building a site with D8, a new piece of software for us, would be a lot more interesting and motivating for everyone involved, so it helps avoid developer burnout.
- Since we do a lot of white label development for agencies and other Drupal shops, having verifiable knowledge of D8 may help us get new clients. (Shameless plug: if your company might be interested in working with us, don’t hesitate to contact us.)
- Only half of our developers have contributed code to the Drupal project so far, but if they run into any issues while working on our website they might develop a personal interest in helping to resolve them.
- There still aren’t many companies using D8 so we are hoping to get some recognition from this while helping other shops by documenting how it goes for us, and hopefully inspiring others to follow in our footsteps.
- Cheppers employees are regular speakers at local and international Drupal events, and building a live website with D8 this early would hopefully provide excellent content for future presentations.
- We have some extra capacity right now so it’s best to use it to improve the skills of our team members.
Cons
- It will definitely take longer. This is made worse by the fact that we can only guess how much longer.
- We expect to have problems upgrading to future D8 releases so the development wouldn’t be a one-time effort. We’ll probably need to allocate significant time for upgrading when a new release comes out.
- We try to avoid replacing members of a project team because it always has a negative effect, at least on the short term, but as we all know sometimes it is inevitable. Since this is not a client project, i.e. is not a top priority, if push comes to shove we will have to take members from this team if their skills become necessary for a client project. With that said, replacing someone on this project would hurt us more than usual because any possible replacement would be less experienced with D8.
- Low number of D8 compatible contrib modules. Enough said.
Fortunately, our office is full of mavericks, so the decision to use D8 was nearly unanimous by the end of this debate. Everyone, even the few holdouts, are excited to move forward with this project despite the added challenge.
So D8 Wins! What’s Next?
I know what you’re thinking, even if the pros outweigh the cons that doesn’t mean the cons are insignificant. What are you going to do about them, you ask? Let me tell you. In order to mitigate risk, we have agreed on the following guidelines.
Make decisions at the latest possible time
With a project like this you really have to work in an agile way. When you know so little about what you’re working with, it’s vital to put off as many decisions as possible until you have a better understanding of what the consequences will be.
No fixed-length sprints
Sprints help keep the focus but at our current experience level we see no point in trying to associate tasks with story points, so we will simply agree on the scope of a sprint. For example, the first sprint’s scope is a fully functional multi-user blog, pretty much like the one you are reading now, and we will abide by the D8 motto, “it will be ready when it’s ready.” Maybe at a later stage we will try to estimate, but not yet.
Continuous improvement
We’ve accepted the fact that we simply don’t know D8 well enough to get everything right in the first attempt. Instead of wasting time trying to find the perfect solution for every problem, we will move on when we find one that’s good enough. Perfection is the enemy of completion and learning from any bad decisions we make will be very valuable to us in the long run.
Use Drupal core only
Drupal 8 is going to be extremely powerful out of the box compared to earlier versions. We hope to achieve all our goals with core functionality and a custom theme.
Re-install instead of upgrade
There are still 10+ upgrade blockers, so we anticipate that upgrading to new releases will break our site. To circumvent this we will create our site as an install profile with automatically imported content.
Automated tests
Since we intend to use Drupal core only, for the time being we’ll be fine with testing CSS regressions only. Inspired by Lewis Nyman’s session at DrupalCamp Brighton we have decided to use Backstop.js for these tests. Thanks for the tip, Lewis!
Document the process
We are going to demo our progress to the whole Cheppers team regularly, as well as post frequent updates on this blog to help others and to get feedback, especially in cases in which we don’t follow the best practices. We would love to hear your thoughts on this post. Is rebuilding our company website with Drupal 8, in its current state, a bold move or a mistake? Are our guidelines reasonable, and will they help prevent potential disasters? Are there any further details you’d like to read about? Let us know!
Related posts
Git is a great tool to keep the code synchronized between developers, but traditionally, Drupal stores the configuration in the database, mixed with the content, so the first step has to be to export the configuration from the database to code files.
A few months ago, I decided to port the TCPDF module for Drupal 8. My first thought was that it would be an easy task, but I ran into my first problem early, when I tried to pull the TCPDF library into Drupal.