Originally published on my blog Web Warrior Toolbox
In this article I write about the workflow we use on daily basis. This is a way to provide the team with simple and easy to understand rules that help them stay in order to have ready to deploy code bases. In this case, we are part of a team where 1 to 3 developers contribute to a code base. We make use of Gitlab and its issue boards to keep track of features. You can refer to these guidelines as a base and adapt for your own team. Be flexible and think about when the rules can be applied a when it is better to device new ways to solve your projects.
How we develop?
1. Listen to stakeholders and take notes
Start by speaking with stakeholders of the project and internal users from the team. This will give an insight of the the core features that define the application—(e.g. profiles, requests, and others). For each area, note the necessary changes and improvements for your project.
After condensing your meeting notes into general issues, you’ll notice that issues usually combine between frontend and backend development work. You can further divide general issues into more specific ones that correspond to back or front end so they can be assigned to a developer.
Example
General Issue: request form
Specific Issue: chevron arrow in select needs spacing (frontend).
Specific Issue: retrieve the select options from a database (backend).
2. Create Feature Branches
Now you have an issue board with general and specific issues. Each issue you create in a GitLab board is assigned a unique number. Use that number as a ticket reference in a conventional branch name. Create the branches you need from master branch or from a general branch as you see fit. You can use vscode extensions for conventional branches and conventional commits to simplify your life in this respect.
3. Merging Strategy: Keep It Simple
Now, regarding merging: keep it simple and merge what you consider makes the process easier to understand. Sometimes it's more practical to merge an specific feature (like chevron arrow spacing of the select element) directly to master. Other times it makes sense to merge it first to a more general branch to test it and make sure it can go to master without making the app crash.
Maintain a single major branch—master. Merge all features into master once they are deemed ready. This approach minimizes the number of Git commands developers need to remember and keeps the branch tree simple, reducing the learning curve for new team members.
4. Using Tags for Clarity and Safety
Use tags on master with version numbers to track what has actually been deployed to production (e.g. semantic versioning). Tags also serve as warnings: when a buggy commit is tagged, others can easily notice and avoid using that version.
Wrapping up
As you can see these rules are flexible and you can use them to evaluate what is worth keeping for your team and what is better to change. Designing a workflow is a continuous activity that can benefit your team by making communication more effective and accelerate the time it takes until production deployment. Since the best pattern varies from team to team, you need to keep notice of your particular conditions and customize the workflow to improve your development time to production.
Top comments (0)