This post is a continuation of a blog series titled, "What is a good plan for implementing a Drupal website/application for organizations?" I previously discussed the need for a solid plan that defines, documents, and communicates a Drupal website/application's requirements. A solid plan leads to a good process for building and maintaining an organization's Drupal website/application.

"Process" is a defacto part of software development. Even if a team has no formal process, the software community has developed ways to define their software projects' success and failures. For example, comparing the number of features a team can implement in a relationship to the number of bugs that the team is required to fix between releases can tell a lot about the success of the team's process.

Open source software development and Drupal do have a unique process. For example, there is no enforced release schedule or best practice for contributed Drupal modules, just guidelines. The Drupal community documents and evolves its best practices and tools to implement stable, reliable, and maintainable code. Implementing Drupal is a process that can present a lot of challenges that need to be considered and addressed.

When managing a team's process for building and maintaining a Drupal website/application, it is important to think about how things are implemented and configured, combined with contributing back to Open Source and Drupal.

As previously discussed, always have a plan and assume things won't go as planned. Because a Drupal website consists of core and contributed modules that work together, there will always be some glue code to connect or to customize the integration of different modules. Glue can get messy and not always succeed in holding things together. Using the analogy of model building related to implementing a Drupal website/application comes down to using the right tools and organizing one's workspace.

The Drupal community has a plethora of guidelines and tools available. It is wise to use Drupal's existing tools as a starting point and evolve them as needed for a team and organization.

Testing is the only way to prevent regressions. I don't like to be preachy about testing, however, I would like to state that "tests confirm expectations" and "any tests are better than no tests." An organization should know that their Drupal website/application works as expected, and tests are the best way to build and maintain this confidence. At the very least, when regressions occur, there should be tests to confirm that the regressions are fixed and will never happen again.

There are a lot of things to configure in Drupal, starting from which modules and libraries are required. Most individual modules require some configuration that needs to be exported. Drupal provides a Configuration Management System, which requires a team to choose a process for maintaining exported configuration.

In most cases, the security of a website is dependent on the proper configuration of users, roles, and permissions. Many Drupal security advisories related to XSS vulnerabilities are mitigated because users must have a certain level of permissions to access the vulnerability. Properly securing API keys and credentials is a vital task that requires a dedicated plan to manage this configuration.

Things never go as planned, and it is best to assume that any enterprise Drupal implementations will require patches. Patches provide quick and shared bug fixes. There are varying levels of contribution. The most immediate and beneficial contribution is helping to troubleshoot and fix issues by contributing to discussions in a module's issue queue on Drupal.org.

In terms of what a reasonable expectation is when considering what organizations should contribute back to open source is not an easy question to answer. The most straightforward answer is an organization should always contribute to anything that immediately benefits the organization. This can translate into, for example, if an organization's Drupal developers see something wrong, they should say something and help fix it.

Good technical leadership needs to help facilitate the process by considering a team's approach to diagnosing issues, mitigating regressions, and finally, pivoting when needed.

It helps to be methodical when managing the process and approach to implementing a Drupal website/application. Scrutinizing the best strategy for documenting and connecting modules can feel tedious, but this will help a team stabilize and maintain their Drupal implementation. For example, I have concluded that an enterprise Drupal implementation should document and track each contributed and custom module's status upon which the website/application relies. Most sites can start with a simple list of installed modules with basic descriptions. This documentation should be improved as modules are updated, especially if updates cause expected regressions.

The level of documentation depends on the team. Teams can use README files, documents, spreadsheets, or a Wiki. The goal of the documentation is to take ownership of an organization's Drupal solution so that the team can mitigate risk.

Using Open source software comes with some risks. The GPL somewhat states, "use at your own risk." The best way to mitigate risk is to assume things will go wrong. When things go wrong, how fast can a team address the issue or regression and prevent the problem or regression from re-occurring? Manual and automated testing is by far the best way to prevent and mitigate unexpected issues and regressions.

Sometimes the best solution to mitigate a problem or limit technical debt is to pivot and change the approach, or even move to a different module to solve a problem.

Expect the unknown with the known fact that Drupal, the software, and an organization's website are constantly evolving. Drupal is flexible, and organizations need to follow suit. In the past several years, there have been significant improvements to Drupal's core page building, API, and workflows support. If an organization wants to future-proof its Drupal implementation, it should maintain a sense of fluidity and move with the community.

Occasionally, if a solution is not working as expected, a Drupal team may need to pivot and look for a better solution or re-approach the current solution. Understanding where an initial solution or decision is coming from, as well as continually tracking where the community is going, can help future proof a Drupal website/application.

The most straightforward approach to creating a good process for building and maintaining a Drupal website/application is to ask a lot of questions, document your solutions, keep up with and hopefully contribute to the community, and always be open to improving and changing an organization's process.

My next blog post will discuss, "What resources does an organization need to build a Drupal team?"

For now, please share your process and insight when building and maintaining a Drupal website/application.