Quality Practices
Roadmap
Everything can be resumen as:
CI/CD
Continuous Integration
Is a development practice that requires developers to integrate code into a shared repository several times a day.
Continuous Delivery/Deployment
An extension of continuous integration to make sure that you can release new changes quickly in a sustainable way
CI
CD
-
Branching Model
-
CI
-
CD
How to make it Happen? 🤷
By phases
Branching Model / Git Mangement
Why is this important?
-
Less conflicts
-
Less errors
-
More stability
-
More readability over the project
-
Parallel work
-
A solid base to introduce more complex procedures (Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Inspection)
It is the core/base/heart of the good practices
Variations
Key Benefits
-
Parallel Development
-
Collaboration
-
Release Staging Area
-
Support For Emergency Fixes
Branch Updated
Each PR (feature branch) at the moment to be integrated to develop should have the last changes, should be above of the target branch.
If the feature branch is outdated, a rebase should be done before integrate it...
git fetch
git rebase origin/develop
How to update a feature branch?
Why?
-
Resolve conflicts before merging
-
Easy bug detection
-
Easy rollback
-
Sequential development
How will look like
Do it Automatically
Develop is Stable
A new feature should be able to start at any time
Why?🤷♂️
- Do not loose agility
- Avoid waiting until a breaking change introduced is repaired
What about Braking Changes?🤔
A change in one part of a software system that potentially causes other components to fail; occurs most often in shared libraries of code used by multiple applications
- Wikipedia
What about Braking Changes?🤔
-
Functions
-
NPM Packages
-
Public vs Private
-
Deprecation
-
GraphQL Schemas
Elements that could introduce Breaking Change
What about Braking Changes?🤔
-
🛑Should not be integrated🛑 until all other projects are adapted to that change
-
Integrate fixes at the same time ⌚
QA team always present on PRs
The QA team should be always present as reviewers of the PRs to perform manual test.
- They have deep knowledge of the entire project
- They know what can be broken with the change introduced
Why?🤷♂️
Do it Automatically
If I don't have QA 😨?
Every Programmer should care 🕵️ about:
-
Test his work
-
Launch to Staging
-
The quality of his work
PR Template
Each PR should follow a template to describe what that PR is introducing
Each Project has its own section and evolves
Each project has its own requirements, restrictions and characteristics.
Each project will integrate the sections on the PR template needed.
Ex: Add an image of the flow changed in a node-red environment
Do it Automatically
PR Labeling
Use GitHub labels to tag your PR
In Case of Braking Change use
Mark it as Draft
Branch Naming
ID
Context
Verb Infinitive
+
A convention to name your branches
+
something to describe what the branch does
ID
Context
Verb Infinitive
+
+
ID
Verb Infinitive
Context
use your ticket id of aha, jira, github issue
✅ do - set - create - fix - build ✅
❌ doing - did - worked- thought ❌
Examples
2354-fix-ci-unit-testing
5654KS-create-config-file
H23D-refactor-old-openclose-feature
Feature branch dropping after merge
Delete a branch after merged to has a clean repo without branches used months ago
Do it Automatically
Reviewer Policy
Depends of the repo/project
Both teams need to make changes on the same repo?
At least one member of the other team needs to be present
To know if that new change will affect something that the creator team is not conscious
Why ? 🤷
Do it Automatically
Who will integrate the PR?
They are sure that the change introduced pass their filter, criteria and is free of bugs
QA Team
Why?🤷♂️
If I don't have QA 😨?
Every Programmer should integrate his own work
If I don't have QA 😨?
Every Programmer should integrate his own work
An error is more expensive to fix when is closer to production
Wo will take care of all of this?
- Each one of us
- The QA team will not integrate the commit if it doesn't follow the rules
- Automagically (do it automatically sections)
Good Practices
Do Small Changes Instead of Big
Is much easier to test and implement
What about big changes 🤔?
-
Create Subtask
-
Create a Feature Branch
Your commits will be much easy to read
<type>[optional scope]: <description>
[optional body]
[optional footer]Common Types:
-
✨ feat
-
🐛 fix
-
👷 build (AKA Chore)
-
♻️ refactor
Pull Request
What to review?
-
Changes fulfill the ticket requirements
-
Impact of the changes
-
Spot bad practices
-
Readability matters
-
Unnecessary changes
Pull Request
Review your own PR
Pull Request
How to resolve comments?
-
Read it
-
Agree or Disagree, give feedback
-
Do not resolve the comment right away
-
Resolve comments after apply changes
Quality on a Project
By Diego Juliao
