The Drupal community is continuously expanding along with the platform’s capabilities. As Drupal development services become more and more complex, it’s getting harder and harder to organize the dev process and structure your approach.
Sooner or later, every web development team faces the urgent need to create a plan or system to make sure that the project stays both scalable and easy to maintain. This is where Drupal development workflow organization comes in handy.
Let’s discover the best practices for engineering a Drupal app and find out how to organize your coding process. We’ll cover both workflow and code writing tips to make your development as efficient as possible.
Implement Version Control
Solo projects are highly maintainable. Since you know your code and very probably understand its structure, there is no problem in adding some new features on top of the existing app. However, it gets really messy when you start working with other people.
Version control systems like Git make it a piece of cake to organize the Drupal workflow management and record all the changes your team has made. Let’s consider a proper version control sequence with the example of modifying the View:
- You make the changes to the configuration or view structure.
- You export the updated files and commit them to Git.
- You synchronize the current version with the committed changes.
- You update the database – whether it’s the test or production one – and refine your results by clearing the outdated cache
As you can see, the sequence is rather simple and easy to follow. While it doesn’t take too much time, version control is integral to efficient time management and correct project organization.
Set Several Server Environments
As the application grows, it gets more and more complicated to develop, test and deploy new modules and features. That’s why you should divide these stages and split your server environment into three parts:
- development environment
- stage environment
- live or release environment
Let’s figure out what each of these is used for.
Development Environment: Your Project’s Sandbox
Every developer or team needs a place to sketch new ideas and make the very first raw versions of future functionality. Development environment addresses this issue by providing the actual sandbox for people to test out their code with no impact on the production version.
Stage Environment: Test It Three Times, Deploy It Once
As you may know, production downtime is always unacceptable. Therefore, you have to test every possible scenario before deploying a new version on the live server. This is what the stage environment is for.
“Why can’t I test on the dev environment?” you may ask. The point is, you often make so many changes during the development that it’s hard to tell whether the dev version is the same as the production. And you must ensure that it is.
The stage part aims to create an environment equal to the live one. You should upload a recent database snapshot to secure the relevance of the data. Deploy and test your awesome app here first to verify its stability.
Production Environment
Only after your module has passed all the tests and is 100% safe for production deployment can you release it. Don’t forget that any bugs that you missed during the testing phase will cost you tenfold to fix when the project is released.
Drupal Development Workflow Tips: Best Coding Practices
While the dev-stage-production sequence is crucial for effective development, it won’t be much help if your techniques are poor or outdated. With that said, let’s improve your Drupal coding habits.
Divide Different Projects: One Codebase per App
When your product grows large, you may be tempted to merge the projects and use the single codebase for several apps. This is where we have to stop you.
You see, having different apps under one source code makes them absolutely unscalable and difficult to maintain. What is more essential, you can accidentally change the behavior of all the products under one codebase by making one small adjustment to it. Not the best scenario, is it? We highly recommend splitting your magnificent code into logically divided code sources.
Hacking the Drupal Core: The Main Taboo
It’s a common fact in the Drupal community that changing the platform core is highly discouraged. By core files, we mean the ones included in the original Drupal installation. But why would you want to hack it in the first place?
The answer is duct taping inefficient workarounds. Let’s be honest here: sometimes we all feel lazy. Implementing a simple yet not the best solution sometimes seems like a good idea. But actually it’s not, especially when you’re a Drupal developer.
Here are the main reasons to leave the Drupal core alone:
- It is a code duct tape. And it’s wrong by definition.
- You just exchange your problem for another one. By modifying core files, you make it exceedingly difficult to update the website, and create subsequent pitfalls.
- You put a stick in other developers’ spokes. Restoring the initial core state and implementing a proper solution won’t be easy. Moreover, future developers will have no clue where to look for your workaround, because, once again, it’s not a common practice.
- You leave space for potential vulnerabilities. You can’t predict the consequences of your interfering with the core, as it’s hard to tell for sure how it’ll work under the core hood. Hence, you can create a serious vulnerability.
Drupal is made to be modular. There should be no reason for you to ignore that and hack the core. After all, you can submit your issue about the needed feature, and it may become an independent part of the official Drupal software.
Keep Business Logic Separate from the Template Layer
From time to time we see projects with business logic implemented in the template layer. Let us explain why this is inappropriate, and what it can lead to.
First things first, your Drupal 8 development workflow should correlate to the platform’s architectural pattern. Drupal is a PAC (Presentation-Abstraction-Control) framework, which implies that the template layer – the Presentation part – should have no intelligence built in. Its primary function is to accept the processed data from the controller and parse it into an HTML page.
Of course, you can always ignore the rules and do it the way you want. However, this raises the two following questions:
- Why have you chosen Drupal if your code doesn’t comply with the platform’s structure?
- How are you going to forward the duct-taped project to new developers?
With that said, don’t place any business logic into a template.
Keep the Balance Between the Module Quantity and Size
As we have figured out, the majority of medium- and large-sized Drupal projects contain custom modules. There can be one, ten, or a hundred modules in your project. But how can you find the middle ground for optimized Drupal workflow?
We believe the following module development tips will help you structure your code into a relevant software architecture:
- Strive to place similar functionality in one module.
- Merge the modules with the same logic.
- If a module becomes intricate and overcomplicated, consider dividing it into several submodules.
To be entirely honest, structure organization is a matter of your preference. However, keeping everything clean and well balanced makes it significantly easier to adopt and maintain your application.
What Else You Should Consider When Developing a Drupal App
Although this framework is powerful and handy at the same time, you still need to take care of your code clarity. We mean both improving the existing code blocks and documenting the new ones. It may seem redundant, but nothing could be further from the truth.
Here’s the kicker: developers spend more time reading code than writing it. While there are no official statistics on this, every software engineer knows that it takes a lot of analyzing and thinking to produce just a few lines of code.
As you may have guessed, the time spent on reading your code decreases as your code becomes clean, structured and, most importantly, well documented. Here are the documentation practices you should work on:
- No comment is excessive. Every line of your code explanation saves several minutes others would spend on making sense of your beautiful code.
- Comment on both what and why. It’s often not enough to understand what your code does. Explaining why you made such a decision helps others to get a much better grasp of your idea.
Following these simple steps, you make your codebase not only a functional app, but an accessible technology.
The Bottom Line
Whether you are a solo developer or a member of a development team, you should organize your dev workflow to make your process more productive and convenient to manage.
Follow the development-stage-deployment sequence, write clean code, comment on all non-trivial parts, and always keep in mind that no site will grow large without the help of others. Therefore, make your Drupal application comprehensible and easy to adopt.
After all, it’s not coding for the sake of coding. It’s about making the Drupal development scope a better place.
