CLI tools is a great way to automate certain tasks for your CI needs. For example you re-use same shell scripts project to project. Or maybe you are integrating with some third-party service. Abstracting these tasks into your own CLI tool could be a great way to go.

You can think about some examples from Drupal world -- each hosting provider has some sort of CLI tool. European Commission has one to automate certain DevOps tasks (https://github.com/openeuropa/task-runner).

When we are talking about tools for local development -- there is a huge variety of options. It is less and less common to set up LAMP stack locally. Instead more developers use docker based environments. In Drupal world there are quite a few of them: docker4drupal, Lando, Docksal, DDEV.

In my last few years I used to work with Docksal and recently also started using DDEV. In this article I would like to demonstrate the differences between the two.

If you are using ElasticSearch with Drupal 8 you most probably use https://www.drupal.org/project/elasticsearch_connector module.

If you are changing the name of the index you can face a situation when your new index is not being picked up. That happens because it doesn't have "mapping". You can solve it in two ways:
* go to index fields section and do some changes there, so it will restore the mapping
* run update index programmatically

If you are using xdebug with PHP Storm and using some kind of virtual environment (docker, vagrant) you can face fairly interesting scenario -- whenever you set your PHP Storm to break on first line -- it picks wrong index.php.

Drupal updates can be very different. Some of them -- easy patches that you just roll out and forget. Some of them -- break your site. Tricky part is you never know how updates will behave on your site until you actually tried them out.

This is why it is very tricky to give estimates to clients how long it is going to take. They usually do not appreciate answer 1 to 20 hours depending on some random facts.

Sometimes when you get new project that is under development for few years you see some obsolete tags and branches in git repo. After you getting approval to clean them up you realize that there are too many of them to be removed manually. In my case about a hundred. Lets see how you can script removing all tags and branches older than 3 months.

Remember to backup your repo before doing all the actions below.

Cleaning up tags

Lately I was working on exposing content with LTI (lti_tool_provider). Main idea is that some content (usually related to learning courses) to be exposed to other systems by embedding it with iframe. There is a OAuth authentication system in place so content can't be reused without authorization.

Testing stale designs

Usually visual testing is very effective when website has stable design that should not be broken.

There are projects the whole idea of those is to keep design the same but to migrate the content to new platform. This is where visual regression testing can help a lot to identify very fast what pages are not yet complete and which ones are 100% accurate and can be shown to client.

The Idea of visual testing of your website has been around for a while. This can range from someone manually checking a web page or more for visual defects or automating the process of detecting visual changes. The cause for unwanted visual changes usually comes from CSS stylesheet changes.

For developers, it is important to understand how to incorporate the visual testing into your existing workflow. As usual there are multiple options out there and we will be listing them below. from the easiest to the most complex.

When we have multiple webheads behind the firewall we need to make sure that each of webhead pretend to be main host. So lets say our main website is www.example.com, all our webheads are webheadX.example.com. With following vhost config we can make sure that when request is recieved by webheadX.example.com it is treated same way as it came to www.example.com