# Radio+ Improvement Suggestion

## Development

1. Full migrates all of source to one repository .i.e. gitlab to bitbucket
2. Attempt to always use the latest API version to develop new/update a feature for the sake of maintainability
3. Follow S.O.L.I.D principle
4. Avoid write down SQL query to query DB, use ORM instead. Write down of SQL query will make the code hard to understand, expecting the output/input, broken code styling
5. Avoid complex join of DB table, better use separation between read table & write table. Read table is a table which optimized for read query (.e.g `view table`), & Write table is a table which optimized to persist/save the data. Please see [CQRS Pattern](https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs)
6. Code style convention. The Convention will shape same development experience when building across application of RCTI+
7. Use statically typed language instead of dynamically typed. Statically typed language will make the application easy to maintain by minimize guessing of output/input & easy to recognize the error trace
8. Write down application setup documentations (Production & Development Setup). This documentation should has prerequisite to run the application (.e.g. OS, required environemnt deps, etc.), configuration docs, development & production procedure. This documentation will help any new adopter could setup the development in agile.

## Deployment Flow

Deployment flow separated into three schemes, general, with orchestrator (Kuberntes) & without orchestrator

### General

1. CI/CD runner shouldn't build the image. The image must be built at `builder instances` which must be identical to another instance, as representative of others to prevent diff between building environment & production environment. CI/CD runner will trigger the `builder instances` to pull, build, & push the new image to container registry with versioning. `Builder instances` could build the image with a base image from the latest version image. The `CI/CD` will distribute this image to each instance (VM/k8s)
2. Testing instance, will behave as instance for black-box testing
3. Before production deployment, CI/CD runner will run an `Unit Test` by black-box testing before distributing to production instances
4. Deploying to Testing instances doesn't need a black-box testing
5. Each add/modify a feature, a developer should write the `Unit Test` for white-box test, then DevOps & QC need to arm in arm write the black-box test since QC knows the details of the feature & will manually test the application later (After deployment)
6. If The latest production deploy need a rollback, the rollback strategy can be done by re-distribute image with the last known best version or others which can be pulled from container registry

### Without `orchestrator` (existing flow):

1. Replication is tricky, because the replication need to initiate a new instance then run the image to them. The new instance need to be registered (SSH keys, etc) to CI/CD runner for distribution of new image

### With `orchestrator` (Kubernetes):

1. Replication can be easily done by give command to orchestrator (.e.g: `kubectl`) for replicating the instance & register the new instance to `load balancer` (If use load balancer)