---
# System prepended metadata

title: General DevOps Pipeline.

---

# General DevOps Pipeline.

Now that we're going to have a dedicated QA team, we as developer need to take the following considerations.

Finishing your sprint means: 

 - You have written some tests.
 - You took care of your code quality.
 - Your local linter passed all the possible errors.
 - The software is running locally.

After you made sure all that passed, you can now MAKE A PULL REQUEST! Depending on the decition from the leader of your team, is the branch you'll choose to push to. 

Common escenarios: 

 - Pushing to staging-branch. 
     - This branch is for testing new features and making an enviroment for the QA team. This is the part where the black-box testing decides if you feature works.
 - Pushing to production-branch (master).
     - If is a production that is not even on production, you can make PR to this one. In this case same as above but with one step less.
     - Otherwise is a real production branch, the only way to push to master is from the staging branch.

## Accepting Pull-Requests

This is easy, pass al the requirements. So the common requirements you'll see are the following: 

- Unit testing passes
- More than 65% of code coverage for staging-branch. 100% for production.
- 2 reviewers needs to aprove your code for staging-branch, 3 reviewers for production. 
    - The reviewers can be: QA Lead, Code Owner, Ricardo or/and Geekxboy.
    - The staging part is not overkill if you are asking. The reason is simply: The code owner will make sure everything is fitting as expected and the QA Lead will make sure the tests are written correctly.

Is worth to mention that pushing to staging-branch or production, will make happen the following:
1. The code will be tested (again).
2. The code will built.
3. In case needed, the build bundle will built into a Docker image.
4. The docker image will be pushed into our private repo.
5. The cluster will be asked to update the software to the most recent version.