My Development Workflow
A dependable workflow reduces the number of decisions made under pressure. Each stage should leave evidence the next person can understand.
Clarify before branching
Write acceptance criteria, identify affected systems, and decide how the change will be verified. Create a focused branch and keep unrelated cleanup separate.
Build a reviewable change
Commit coherent steps, run automated checks locally, and explain risk and test coverage in the merge request. Screenshots or request examples help when behavior is visual or integration-heavy.
Deploy with a recovery path
Know the database and configuration steps, monitor the release, and define rollback or forward-fix criteria. Update documentation while the reasoning is fresh.
Working example
git switch -c feature/journal-search
composer install
drush updatedb -y
drush cache:rebuild
git diff --checkMake local reproduction cheap
A development environment is most useful when another developer can reproduce the application with a small, documented sequence. Dependency installation, database import, configuration, and common Drush operations should not rely on one person's shell history.
That reproducibility also improves debugging. If a failure occurs only in one environment, the differences are easier to investigate when the expected environment is encoded rather than remembered.
Separate code, configuration, and content movement
Code and deployable configuration move toward production through review. Production editorial content normally moves in the opposite direction when developers need realistic local or staging data. Mixing those directions can overwrite real content or allow unreviewed structural changes to appear on production.
Knowing which category a change belongs to is an important part of planning the release.
Verify after the deployment finishes
A pipeline completing successfully is not the same as the application working. I want Drupal to bootstrap, the database to connect, configuration to be synchronized, database updates to be complete, important public routes to return the expected responses, and the site to be out of maintenance mode.
Those checks turn deployment from "the commands ran" into "the application reached the intended state."
Key Takeaways
- Clarify acceptance and verification first.
- Keep branches and commits focused.
- Deploy with monitoring and recovery criteria.