diff --git a/Software-Development/README.md b/Software-Development/README.md index 48c5b89..ec8ca88 100644 --- a/Software-Development/README.md +++ b/Software-Development/README.md @@ -1,4 +1,4 @@ -# **A Developer's Guide to Software Development at DIT** +# A Developer's Guide to Software Development at DIT @@ -35,7 +35,7 @@ -## **General Software Development Requirements** +## General Software Development Requirements ### Use of existing tools @@ -51,7 +51,7 @@ Close-sourced libraries require internal approval. We do not allow closed-source -### **Separation of Environments** +### Separation of Environments Information and configuration must not be hardcoded in the software codebase whatsoever (i.e. Database connection string, external service URLs, IP Addresses, host names, etc). These configurations must be designed in such a way that it could be set to different values in different environments. @@ -175,7 +175,49 @@ In case of command line applications, an option must be provided (suggestion – ### Version Control and Repository Management +All code must be controlled using Git. The code bases must be stored in independent repository in a single-application-per-repository fashion on GitHub. No repository shall contain more than one software component. +#### Git + +All software code bases must have a branch named `main` that acts as the default branch. Changing the default branch to be something else is not regularly permissible unless authorized by the Head of DevOps. + +##### Branching + +Conventionally, each code base must also have a branch that corresponds to an identical deployment environment. For example, the branch `dev` corresponds to codes running in an `dev` environment, `staging` to `staging`, `pre-prod` to `pre-prod`, and `main` to`production`. + +All code bases must have a branch that corresponds to a major version. For example branch `v1.x.x` must contain all initial codes. The next major release must also get its own branch `v2.x.x` which is typically created off `main`. (Edge cases must be explicitly authorized by the Head of Digital Development or DevOps). + +The order from which branches are merged generally takes the following form: + +`major version branch` -> `dev` -> `staging` -> `staging` -> `pre-prod` -> `main` + +An example: + +`v1.x.x` -> `dev` -> `staging` -> `staging` -> `pre-prod` -> `main` + +All the minor releases and patches within the same version follows the same flow. However, in the next major release, it takes the next form: + +From `main` create `next version branch` -> `dev` -> `staging` -> `pre-prod` -> `main` + +An example: + +From `main` create `v2.x.x` -> `dev` -> `staging` -> `pre-prod` -> `main` + +##### Merging and Pushing + +All developers are free to push to the release branch and `dev` whenever they would like to. However, pushing to any branch other branch requires a Pull Request that needs review and approval. + +Below is an overview of the policies: + +| Branch Name | Authorized Parties | Review Policy | +| ------------------------ | ------------------------------------------------------------ | ----------------------------------------- | +| Release / Feature Branch | No restriction | No review required | +| dev | No restriction | No review required | +| staging | Authorized by Head of Digital Development or DevOps
Team Leads | No review required | +| pre-prod | Authorized by Head of Digital Development or DevOps | At least 1 review by Head of DD or DevOps | +| main | Only Head of DevOps | At least 1 review by Head of DD | + +#### GitHub ## Distributed Computing Specifications @@ -239,9 +281,19 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( +### Statelessness +### Race Condition +#### Concurrency +##### Optimistic Concurrency + +#### Application Architecture Design + +#### Database Design + +#### Message Brokers @@ -251,7 +303,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( ### Accepted Technologies and Development Stacks -#### **Option #1 (Alpha): **The Overnight Master**** +#### Option #1 (Alpha): The Overnight Master**** 1. Ruby Programming Language (version >= 2.2) 2. Ruby on Rails Framework (version >= 5) @@ -270,7 +322,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #2 (Beta): The Veteran** +#### Option #2 (Beta): The Veteran 1. PHP (version >= 7) 2. Laravel (version >= 7) @@ -284,7 +336,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #3 (Gamma): The Dilemma** +#### Option #3 (Gamma): The Dilemma 1. Elixir (version >= 1.9) / Erlang Programming Language (version >= 22) 2. Phoenix Framework (version >= 1.5) @@ -299,7 +351,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #4 (Delta): The Polymath Developer** +#### Option #4 (Delta): The Polymath Developer 1. Python Programming Language (version >= 2.7.13) 2. Django Framework (version >= 3) @@ -318,7 +370,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #5 (Epsilon): Iron Dome** +#### Option #5 (Epsilon): Iron Dome 1. C# Programming Language (version >= 8) 2. Frameworks: @@ -339,7 +391,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #6 (Zeta): The Enterprise Beast** +#### Option #6 (Zeta): The Enterprise Beast 1. Java Programming Language (version >= 8) 2. Runtime Environment @@ -359,7 +411,7 @@ We also recommend reading the official [Best practices for writing Dockerfiles]( -#### **Option #7 (Eta): The Mighty Node** +#### Option #7 (Eta): The Mighty Node 1. Programming Languages 1. JavaScript Programming Language ( >= ECMAScript 6)