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

  1. Branching Model

  2. CI

  3. 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

Gitflow

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

Angular PR Template

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

Use Conventional Commits

Your commits will be much easy to read

<type>[optional scope]: <description>

[optional body]

[optional footer]

Use Conventional Commits

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

Made with Slides.com