How Drupal support works in Droptica

In my previous post, I described why we created a separate Drupal support team. In this post, I will describe how our Drupal support team works.

Objectives of the Drupal support team

Drupal support team in Droptica has 3 main objectives:

1. Keep all the websites up and running

Many of our customers rely on their websites being operational. Often the applications we maintain run or are the core of the business of our clients. Downtime equals complaints, lost revenues etc. 

Our support team focuses on making sure that the websites work and quickly react to any issues or errors that arise. 

2. Keep the websites secure

Security releases of Drupal core and modules come out all the time. The same is true for technology stacks running Drupal - server software, PHP versions etc. Our support team ensures that all websites are up to date and do not have any known security vulnerabilities. 

When a Drupal security update comes out, we have to update over 100 websites as fast as possible. To do that we have streamlined processes and workflows which are maintained by our support team.

3. Provide small development services

Many websites after an initial development stage do not require a full-time development team. Almost every website, however, needs some work from time to time. Either a new landing page or a new integration or perhaps some bug fixing or problem-solving.

As long as the development effort is not extensive, our support team helps also with these tasks. If new features require a bigger effort, the work is scheduled and handed over to one of our dedicated teams of Drupal developers.

The support process

In Droptica we automate as much as possible. To ensure that we do not waste time and that we deliver the most predictable results, all websites follow the same process.

There is an automated testing environment

Each website we take over for support goes through an onboarding process which allows us to maintain it easily going forward. During the onboarding we create the following:

1. A replicable development environment on Docker, which resembles as much as possible the production environment. 
2. An automated testing environment, accessible to the client (a test website). This is where we stage work for our clients for them to inspect before deploying to production. Clients can also use this for their testing and training purposes. If a need arises, we can create multiple such clones of the website.
3. An automated process of duplicating a production website onto development and testing environments. This process allows us, with a click of a button, to copy over the latest version of the production website into any environment and deploy new code to it. 
4. An automated deployment mechanism, which enables us to publish new changes to production quickly and predictably

Thanks to the automation, we can quickly (within a few minutes) copy a production website to development, inspect an error and create a fix for it, push it to the testing environment to test deployment and also to present to the client. If accepted, the change quickly can be automatically pushed to production.

Support request workflow

We encourage our clients to use Jira but some of them prefer email or Skype. Whichever the method of communication, we log each request to Jira. This is when the life of the request begins. Depending on severity, urgency, type of request and client support package, the ticket will be scheduled accordingly and will wait for an available developer to pick it up. 

After multiple trials we now have the following statuses in Jira to describe the stages the ticket can be in:

1. To Do - the ticket is new. No one worked on it yet.
2. Needs Work - the ticket was started but is not finished and not actively worked on at the moment. This can be a ticket that did not manage to get past our Quality Assurance team and was returned to be improved or a ticket that was started but the developer had to move to something more urgent.
3. In Progress - a developer is currently actively working on this ticket. This is done in a separate branch in git which will be merged with the main branch only when it passed QA. This ensures that we ship to production only tested and working solutions.
4. Feedback/Impediment - the ticket needs input from the client or someone (eg. external provider) and we are waiting for more information.
5. Code Review - a developer finished working and created a pull request with code. It now awaits for code quality review. A senior developer will review the code to check if it is correct, makes sense and whether it maintains Drupal standards.
6. QA - ticket passed code review and is now in testing by our testing (Quality Assurance) team. Types of tests here might vary from basic manual checks to extensive automated regression testing of functionality and appearance. Typically QA will automatically build a test version of the website on the developer's branch of core and will perform all the necessary tests. If the tests pass, the client is informed that he can test the solution if he wants.
7. PO Review - (Product Owner review) - we believe we finished working and presented the ticket for review to the client on a testing website.
8. Ready To Deploy - Product Owner accepted the work and it is ready to be deployed to production.
9. Done - the code is deployed to production. Work on this particular ticket is finished.   

The above nicely describes what happens to each request. Thanks to automation we can easily work on various tickets in parallel, test them and deploy them to production safely and predictably. 

Websites of our clients are well taken care of.