Development Flow
On the developers side, each element containing a piece of functionality to be delivered (deliverable) should follow the same steps. These steps are reflected on grid stages and element tasks.
Summary
- Consultation on Architectural Considerations
- Decide on feature delivery
- Create a Pull Request for Validation (implementation)
- Testing Process and Bug Fixes
- Merge the Pull Request
- Deploy
1. Consultation on Architectural Considerations
Before initiating development, collaborate with team members to discuss architectural considerations. This consultation helps in understanding existing systems, aligning the feature with the overall architecture, and foreseeing potential integration challenges.
Depending on what unknowns there are, it can be beneficial to set up a reviewing process after a proof of concept has been developed. This will increase alignment and decrease the chances of finding critical architectural problems at the end of the development process.
2. Decide on Feature Delivery
Depending on feature complexity, length and developers involved, decide if this feature will be delivered in one go or multiples. It's a decision to be made by the feature authors taking into consideration the rest of the team. The intention is to improve the review process and reduce PR size.
There is no rule on size but, as an example, anything past 50 commits becomes difficult to review. The rule is: as many sub-deliveries as possible without being cumbersome. It is a clear trade-off between bureaucracy and code coherence by review.
Possible separations:
- Significant BE and FE code - This code will be reviewed by different roles and does not affect the same code base (ideally)
- Multiple developers - Each delivery should be authored by only one developer, others might contribute but the less the better
- Logical steps - Some features can be split into clear steps
- Different modules - Some features affect separate app modules or services
2.1. Multiple sub-deliveries
In case it's decided this feature would incur multiple sub-deliveries, each one should create a new branch from feature branch to tackle each one of them when appropriate. For example, if a feature is split between FE and BE, create a BE branch to tackle BE code and only create FE branch once needed, either because BE branch is merged or FE can start without it.
When branch is finished and tested by the author, it should be pull requested into feature branch and reviewed by relevant roles. QA does not play a role in these deliverables as they will not be actually delivered.
Once all sub-delivery branches have been merged, the process continues as normal (PR, QA…). Commits can be performed on feature branch to correct bugs or integration problems. Try not to abuse this.
2.2 Single delivery
Tackle the feature by committing directly on feature branch. Write clean, maintainable, and well-documented code, adhering to the team's coding standards and best practices.
3. Create a Pull Request for Validation (implementation)
After completing the feature development, create a pull request for coworkers to validate the implementation. This step ensures that the feature has been implemented according to the agreed specifications and doesn't introduce unexpected issues in the existing code base.
4. Testing Process and Bug Fixes
Submit the feature for rigorous testing. If bugs are identified during testing, promptly address them. Make the necessary corrections and ensure that the fixes are validated through testing.
5. Merge the Pull Request
Once the feature has passed all testing phases and the bug fixes have been validated, merge the pull request. Ensure that the merge is performed following the team's version control guidelines. Document the changes made, update relevant documentation, and communicate the successful implementation of the feature to the team.
6. Deploy
Deploy the feature according to element tasks. Coordinate with testing department to test what has been delivered and ensure functionality post delivery.
Conclusion
A well-defined feature development flow, incorporating consultation, validation, testing, and bug fixing processes, ensures the delivery of high-quality features. Collaboration and communication among team members are key to successfully implementing features that align with the project's goals, maintain the code base quality, and meet user expectations.