The document outlines a step-by-step development process that emphasizes the use of version control systems (VCS) and application programming interfaces (APIs). It details the proper use of branches in VCS, including main and sub-branches for managing feature and issue development, as well as the best practices for testing and deploying code. Additionally, it discusses the importance of documenting and testing APIs using tools like Postman to facilitate collaboration between developers.

1. Development Process
Step By Step You Will Know The Propper Development Process From VCS
To API During The Development.
By: Mohamed Alaa El-Din Mohamed.
V1

2. Development Process
The Development Process Simply Shows The Steps That You Should take During
The Development.
Most Steps That You Should Be Aware With, You Will Find It Here
 VCS
 API
 Open Source Projects
 Testing

3. Version Control (VCS)
Version control is a system that records changes to a file or set of files over time
so that you can recall specific versions later.
Here Proper Way To Use The VCS During Your Development:
 Branches
 Amend
 Merge
 Stash
 Reset

4. VCS: Branches
 Branches Are Like The Time Lines, You Can Create New Time Line (Branch)
And Develop On it With Out Effect The Original Time Line (Master Branch).
 This Is Very Useful During Developing A Project With Many Maintainers And
Developers, So You Can
 Create New Branch For Your Work
 Then You Can Merge It To The Staging Branch or The Production Branch (Will Come
Soon Later) After Finishing The Development.

5. VCS: Branches : Branches List
We Have 2 Different Branches List To Can Develop The App With Proper Way
Without Any Hassel In The Code And Testing The Branches Lists Are:
 Main Branches
 Sub Branches

6. VCS: Branches : Branches List : Main
Branches
 Develop Branch
 Branch Name Should be develop.
 If You Have Back/frontend In Same Repo So The Name Convention Should Be develop-backend/develop-frontend.
 Here All The Just Finished Features/Issues Are Merged From The Sub Branches.
 Here Is Where The White Box Testing Should Take Place.
 Staging Branch
 Branch Name Should be staging.
 If You Have Back/frontend In Same Repo So The Name Convention Should Be staging-backend/staging-frontend.
 Here All The Features/Issues That Is Tested And Merged From The Development Branch
 Here Is Where The Black Box testing Should Take Place.
 Here Were You Should Test The App Is It is In Production.
 Production Branch
 Branch Name Should be production.
 If You Have Back/frontend In Same Repo So The Name Convention Should Be production-backend/production-frontend.
 Here All The Features/Issues That Is Tested And Merged From The Staging Branch.
 Here The App Should Be Deployed To The Client.

7. VCS: Branches : Branches List : Sub
Branches
 Feature Branch
 Proper Name Should Be feature/feature-name
 The Feature Should Be Developed And Tested Individually.
 Finally It Should Merged With Develop Branch (Main Branch)
 Issues Branch
 Proper Name Should Be issue/issue-name
 The Issue Should Be Developed And Tested Individually.
 Finally It Should Merged With Develop Branch (Main Branch).
 Some Times It Should Merged With Staging Or Production As Well.

8. VCS: Branches : Branches List Diagram

9. Application Programming Interface (API)
 Simply It is The Blocks Of Code That Any App is Needed To Be Build.
 Good API Make It Easier For Developer Or Maintainer To Build Their App Just
By Calling This API End Point.
 It Should Handling The Request, Validation And Response For The Client.

10. API: PostMan
For Developing Proposes Developers May Test Their App By Many Use Cases And
For The API It’s The Same The Developer Should Test The API And Provide A Proper
Information About it.
Post Man Is The Common Used App For This Cases.
Here We Will Discus The Proper Way To Document And Test Your API.

11. API: PostMan
PostMan Can Create A Collection Of Requests So We Will Discuss What Should The
Request Have:
 The Request Should Have A Very Clear Name.
 The Request Should Have A Very Clear Description.
 Query Params That Used.
 Parameters.
 Notes.
 Description About The Request.
 The Request Should Have A Clear Headers Set.
 The Request Should Have A Clear Body Data And Should Be Human Readable.
 The Request Should Have Examples For The Success/Failed Responses.
 Optionally Make Test For The Request.

12. API: PostMan
 After Create The Collection Of Requests You Should Publish It For The
Frontend Developer So He Can Work With It.
 Don’t Wait Until You Finish The Collection To Publish it, Make Basic Requests
And Publish It For The Frontend To Not Make Him Wait.
 During The Frontend Using The Publish Docs/Collection Start Develop The
Other Features And Write The Other Requests.