# Development Workflow

AutoWeb projects are Git Repositories managed by Azure Repos. All the projects are being worked with a workflow crated by the team, taking adventage of ephemeral enviroments and a lot of automations that make the development process as easiest and agile as possible.


## Branches:
**Master** is the main branch and will be deployed to production sites.

The branch where developers will start new features and integrate all tested features before going to production is **develop**.

**Staging** is the final control point before going to production, QA team will perform UAT Testing in this branch.

**Ephemeral** branches are temporary workspaces where developers will create new features and QA team will perform their first tests before integrate them with other features in **develop**.

All the principal branches are protected by security policies:
* **Pull Request:** Every time the development team want to push new changes to any principal branch as develop, staging or master, this process must be treated as a Pull Request
* **Team Review:** Every single Pull Request will ask for a pair review, the reviewer must be a different person from the PR creator.
* **Associated Work Items:** The Pull Request must be associated to at least one user story
* **Merge Type:** Only basic merge will be available.

### Automation Process for Develop, Staging and Master

**Build:** After completing a Pull Request under any of the principal branches, a pipeline for creating the Docker Image will be triggered, this pipeline is called "Build_*Name of the repository*_V2, ex: Build_Anaconda_V2", pipelines can be found in the path: [Pipelines -> All/Builds](https://dev.azure.com/Autoweb-DevOps/TeamCobra/_build?definitionScope=%5CBuilds).

**Release:** In the case for develop, the deployment will be done automatically, but, in the case for staging and master, a release pipeline will be triggered after the build is finished. Release pipelines will ask team members for accepting the deployment, in the case for staging, the pipeline will ask QA Team for accepting this new version in the web application, for master, the release pipeline will ask Business Team (team stablished by the client) for going live to production. Release pipelines can be found in the path: [Pipelines -> Releases -> All Pipelines / New Workflow V2](https://dev.azure.com/Autoweb-DevOps/TeamCobra/_release?_a=releases&view=all&path=%5CNew%20Workflow%20V2).

## Workflow:

For starting a new feature development the development team can use the next steps.

### 1. (Developer) Create Infrastructure:
The developer can ask a DevOps Engineer to create the infrastructure of the new branch, but, if not DevOps Engineer available, the developer can also create the infrastructure by itself by following this guide: ---

### 2. (Developer) Create Ephemeral Branch:
The developer must pull all remote changes from develop to its local workspace, then, create a new branch from develop called "ephemeral/*name_of_the_feature*", the name of the feature must not exceed 20 characters, otherwise, the infrastructure won't be created. After creating this new branch, the developer can start to work on the new feature. Everytime the developer pushes any commit, the pipeline will automatically deploy those changes into the ephemeral environment if there are no code errors. The pipelines for this automation process will print the environment URL.
#### Automation Process:
There are two pipelines running for the ephemeral environments, the first on be triggered is called "Trigger *Name of the Repository* Ephemeral, ex: Trigger Anaconda Ephemeral", the second one on be triggered is called "BuildAndDeployEphemeral-*Name of the Repository*-V2, ex: BuildAndDeployEphemeral-anaconda-V2", this second pipeline will deploy the new image of the ephemeral environment to the infrastructure, the developer can check the URL of this site in the task "AzureWebAppContainer" under the stage "Deploy Ephemeral". This pipelines can be found in the path: [Pipelines -> All/Builds/ephemeral](https://dev.azure.com/Autoweb-DevOps/TeamCobra/_build?definitionScope=%5CBuilds%5Cephemeral). For more details please check this video:

### 3. (Developer + QA) Start Testing:
When the developer has already finished the feature development, one of the QA members must be notified for starting the QA testing on this ephemeral environment, checking the feature is working as expected.

### 4. (Developer) Integrate to Develop:
If everything goes well after QA testing, the developer will be able to create a Pull Request from the ephemeral branch to develop. After completing the Pull Request and once the pipeline has finished , the developer should start tests for checking the correct behavior of the site with the integration of all the features.

### 5. (Developer + QA) Integrate to Staging:
After checking everything is working fine in develop, the developer can now start a Pull Request from develop to staging, after completing the PR and once the pipeline finished, a new release pipeline notification will be sent to QA team waiting for their permission to deploy the new version in the staging environment. This release will also show the QA team what work items are related in the new version. After QA approval, the deployment to staging environment will be automatically applied.

### 6. (QA) Start UAT Testing:

When the changes are already deployed in staging, QA Team can start UAT Testing before going to production. If there is any issue with the new changes, QA Team must create a new ticket (Type: Bug) with information related about the failure(s), then, the developer can start working on this.

### 7. (QA) Integrate to Master:

If there are not any issue in staging and everything is working as expected, QA Team will have to create a new Pull Request from staging to master, after the PR gets completed and the build pipeline has finished, a new release will be triggered asking permissions to Business Team for going live to production, this release will send an email that contains all work items related, after business approvals, the release will deploy the last version of the project to the production site.