| layout | post |
|---|---|
| title | Development Best Practices |
During the kickstart process, we have some requirements that we feel it's mandatory for a healthy project development lifecycle:
- Amount of hours per week/month and which people are going to participate
- Requirements documentation / API documentation
- UI Documentation
- Project board for management (modules and features set up based on requirements)
- Project board for development
- Repository created in our GitHub account with our standards.
The project won't have its kickstart while we have our requirements checked up.
As a mandatory behavior, all developers need to attend to the following implementation process:
- start coding
- e2e implementation (test scenarios needs to be mapped on planning at Asana's)
- run tests locally
- validate implementation
- pre-commit analysis before sending to repo
- open a pull request
- check if CI/CD passed
To kickstart a project at Mobix, we need to evaluate the project complexity as well as the type of architecture.
On regular projects we develop, we avoid starting from scratch - we have our standards for each project we develop. Thus, we can keep good maintenance and also share internally our practices and keep always the culture of improvements.
We set up some hours during the week/month in our team's allocation to check our boilerplates. Usually, we share some good practices we used in some projects with our clients and put it together for future challenges.
At Mobix we introduce a configuration model tailoring the best practices of code configuration.
Tailoring the project structure, we define two main branches:
- main
- staging
- develop
Where master tags the production version of the software. In that scenario, the version we deploy and go-live is tagged with its specific version.
homolog delivers the current version of the project to validate our results with our client. We also keep our track on QA assessment before going live.
Regarding develop, we merge all implementations that we do in our team to validate the sprint.
Outside those two main branches, we define the following approach:
- feature - for new implementations
- issue - for bug fixes or small adjustments
- hotfix - for critical fixes
- release - to tag a version for going live
For each Pull Request opened, we apply CI/CD as a preview integration a delivery. We validate not only what was implemented, but also check if the tests were done correctly.
Our PR has the following template:
- PR Title: [JIRA-ID] Summary of your Pull Request
- Summary
- What has been implemented
We also have a culture of Code Review for each PR, where we verify code practices and check quality and performances that we might need to improve.
Technical debts are one of the most important topics around software development. The need to tackle and avoid debts into our code is one of the things we keep on track to improve our projects.
We use Code Climate to check all maintainability/code smells and test coverage report in the project and set up a moment during the Sprint cycle to check all comments regarding our code and tests. The whole team participates in this event, getting good and deep thoughts about the way we are coding.