Configuration management, theory and practice
Presented by guys from Nuvole, a Drupal agency based in Italy / Belgium / Czech Republic, this talk ran through all the good things in Drupal 8’s configuration management.
First challenge: how do we deal with fast updates, with multiple developers on a project and frequent deployment of config changes.
Exporting and deploying configuration in Drupal 8 is now possible. This is a tool built for a specific purpose, to export the whole configuration for a site, and it is perfect for this purpose. But new issues are emerging many of which are being addressed in contrib modules.
How do I start a site from existing configuration?
The default D8 config management allows us to export configuration but only import it to a copy of the same site. Enter: https://www.drupal.org/project/config_installer. The idea here is that the installer will ask for config to import while installing a site: this is not in core yet, but hopes to be in the future https://www.drupal.org/node/1613424
Can I override local config?
When developing it is often useful to override configuration locally for example API keys for local development or setting verbose logging on local machine but not in production. One way to do this is with local config overrides, such as:
$config['system.logging']['error_level'] = 'verbose';
BUT the settings in the UI will still look like the original setting not the overridden configuration. This is to prevent accidental export of the overrides.
Mutable vs immutable config: Drupal can load configuration which is either read only or editable.
Issues with this method of overriding configuration:
- you can’t add new configuration
- you can’t enable a module locally
- you can’t unset configuration
How to exclude development modules from being exported with other configuration?
drush cex —skip-modules=devel
2. Drush drush_cmi_tools
drush cexy —ignore-list=modules_to_ignore.txt
3. Configuration split
This is a neat way to divide configuration into different folders.
Working on configuration with colleagues
As config is file based, git does a pretty good job of merging configuration changes and resolving conflicts, but we can still run into issues resulting in invalid configuration.
Features for Drupal 8
Features in Drupal 8 is mainly for the automatic packaging of configuration; it is not for deploying changes to configuration! Features should now be considered a development module, and should never be committed to production environments. An interesting byproduct of configuration management and features is that generated features DO NOT depend on the features module! We can deploy and enable them on their own. Neat!
There are however a number of gaps in the features config packaging at the present time:
- menu links
How can I handle a client messing with config on prod?
Changing configuration is an ACT OF DEVELOPMENT! So clients who change configuration become a developer that you cannot control. There are a number of ways we can address this.
$settings[‘config_readonly’] = TRUE;
- Even a client with access to the UI to change config, will not be able to save any changes. Harsh, but clean.
- Export to a dedicated branch
- use a git workflow where changes on production are allowed and merged into another branch test deployment of new changes.
- Config split.
- define the subset of configuration that a client can edit, and use config split to export this configuration to this directory. We can then use git ignore to avoid committing and deploying such configuration (and overwriting changes made on the production site).
How can we deploying configuration that has dependency on content?
This module helps us to export content using drush, then include that default content with the module. This could include menu links, nodes, terms.
Or... we could use Deploy an amazing module, but quite heavyweight if we just need a few items of default content.
Here is a list of modules that may be useful when extending configuration management. Who knew there were so many?
- Configuration installer
- Configuration Read-only mode
- Configuration_Update Manager
- Configuration Split
- Configuration Tools
- Configuration Synchronizer
My key takeaways
- Consider client side configuration allowances at the start of a project and clarify expectations within the team.
- Try Configuration Split module.
See the video of this session:
Super Collaborative Design Processes.
Lewis Nyman has always had plenty to say about front end in Drupal. He used to live in Oxford and has worked with Agile Collective on User Experience, so it was great to hear his thoughts about collaborating more with clients on the design process. He now works at Convivio.
What do we need from a good design process?
- consensus based on objectives (not opinions)
- buy in from stakeholders
- buy in from developers
- good design – it is important that we all feel good about the design
With a show of hands, Lewis assessed the makeup of the audience in the room
- mostly developers
- 20% pm / project owners
- 5% designers
Old process for UX design
- go into a cave
- decide what was best
- present to the client
- get feedback
Some of the feedback was often difficult and not that useful
- 'can we make it green?'
- 'I think it should like Amazon / Tinder / Uber'
- ' ' – (silence, no feedback)
- 'I don’t like it'
- 'Hello, I don’t like it, Goodbye' – (swoop and poop) often by a HIPPO (Highest Paid Person’s Opinion)
- 'I’ve brought my own wireframes'
- 'Ooh that’s going to be expensive to build'
New ways of working include
- UX workshops
- design studio
- design sprint http://www.thesprintbook.com/ (Jake Knapp)
Bringing everyone together to develop ideas and design decisions
- product owners
Workshops help to
- understand and define the problems
- generate ideas
- then focus on an agreed approach
Share information with everyone (get people to take notes)
Define the problem(s)
Start by agreeing on the problems that we are aiming to address. An example of this may be:
- 'Students don’t receive enough guidance on how to develop the skills that will enable them to learn and flourish.'
Get started with pen and paper. Use exercises to warm people up such as 'squiggle birds' or '60 second portraits'.
Generate as many ideas a possible, and remember:
- all ideas are equal
- don’t judge
- don’t analyse
- ideas don’t even need to be feasible
Techniques that can help
- 6-8-5s - http://gamestorming.com/games-for-fresh-thinking-and-ideas/6-8-5s/
- 6-ups - https://asset.uie.com/articles/pdf/design_studio_workshop/six_up_template.pdf
It is important to get everyone past the first idea hump. Someone has usually been building an idea for a while and they become quite attached to that idea, shooting down other people’s ideas. Getting this out on paper will allow them to move past this and generate more ideas.
Present all ideas
Get all ideas up on the wall next to the problem statements. Talk through all ideas to build mutual understanding.
If everyone is facing the same direction this is less intimidating. Dot voting can be used to rate interest in each idea and help generate consensus.
Generate more ideas!
Boil it down
- identify any conflicting ideas, ideas that are either one of the other.
- use 3-12-3 as an extension to the 685s, this can be used to develop three ideas in more detail.
- extend ideas with more detailed storyboarding.
By engaging the client in workshops we will develop a better design and ensure more buy in at an earlier stage. By focusing on our ideas together in person we potentially get through two weeks of work in 6 hours.
HIPPOS: any suggestions for how to deal with them in a workshop?
They often feel like they've not been listed to, give them attention, get it out, then generate more ideas.
This sounds like it is still very much at the wireframe stage of user experience. What about visual design?
Still need to iterate on visual design, but it is more likely that we will have already agreed the structure of the pages / screens so this will be more efficient and will happen faster.
My key takeaways
- Defining a collaborative UX and visual design workflow is important for efficiency and buy in.
- Using new techniques within workshops such as 6-8-5s will help focus and encourage idea generation.
- http://www.thesprintbook.com/ sounds like an interesting read.
See the video of this session
BOF – Does Drupal need a Platform Co-op?
Birds of a Feather (BOF) sessions at Drupalcon are ad-hoc meetings that allow attendees to discuss issues that crop up during the conference. This session was proposed by Steve Purkiss who wanted to discuss the idea of a Drupal platform co-op. There were representatives from three Drupal co-ops: Agaric Collective (US and Nicaragua), Agile Collective (UK) and Point Blank (Greece). A number of freelancers and people interested in the discussion also joined.
Steve Purkiss’s motivation for setting up a platform co-op: to be more in control of working environment and client relationships. To allow freelancers and single person companies to work with others to appear larger. When asked to define a platform co-op, the example given was 'a company like Uber which connects customers with suppliers, but one that was owned by the customers and suppliers'.
We discussed whether this was different from the roles of the Drupal Association and Drupal.org and didn’t really get to anything conclusive. We explored the idea of a Drupal trade association (something mentioned by Robert Castello when discussing a national UK Drupal association) and I mentioned that other tech co-ops in the UK are getting together to discuss ways of working together in a similar manner.
In summary, those of us who already work in a worker co-op couldn’t really see the added value of a new Drupal platform co-op. Steve clarified that he doesn’t want to work in a company, but would like the opportunity to work on larger projects as part of larger teams. I’m not sure how these two can be resolved.