Github Project Setup and version control

Repository Structure
1 DataBase directory:
1) Every repository must have one database directory on root.
2) Always need to maintain initial database sql file required for fresh setup in database
directory.
3) Need to maintain one db-update.sql file with repository files inside database directory
which we need to include all the db related updates (Like create statement/ Alter queries
or maybe insert statement if needed). This file must be emptied after each release. In
other words, this file will contain all the queries required to upgrade from previous
release to this release.
4) At the time of release we need to put blank_db.sql file (Contains some necessary data)
and db_withdata.sql file inside database directory.
5) At the time of release we need to update CONF_WEB_APP_VERSION in conf-common
file.

2 Readme File:
1) In our repository we need to maintain a readme.txt file in which maintain all the
changelog of that release. This file will contain user facing information not developer
specific. Like, it should contain “Added support for xxx” and not “Changed basecontroller
to xxxx”. It should contain specific notes or instructions for upgrade etc if needed.
2) Don’t delete any previous line of comment which we mentioned earlier.
3) Every Comment should be added as a new line.
4) Before release check all the points/comment mentioned in the file and place only few
points like :
a) What’s new (features) with this release.
b) What’s updated with this release.
c) What’s fixed with this release.

Note: After every release this file need to set empty.

Branches:
Every work should start by creating a separate branch and branch name should be as
below :
task_{task id}_<branch_name>
bug_{bug id}_<branch_name>
Branch_name : It should be self explanatory so that we can easily identify that on which branch
we are currently working.

Examples: task_1112_registration_module , task_1112_login_module etc..

How to do Commit
We need to commit all the work once any point will be done based on task and commit should
be like :

task-{task id}-{Reference point number}-{message}

Or
bug-{bug id}-{message}

Reference point number : It is subpoint defined in task if you are commiting with partial task
completion.

In message, you can include FRD-xxx for FRD points or similarly for any reference if you wish to
keep.

Example : Suppose we had started work based on TASK (task id 1112) and in TASK there is one
point registration functionality and we completed the task till email verification process(1.1)

1) Registration functionality
1.0 Create registration screen and submit user info.
1.1 Email verification process.
1.2 Register user and welcome email.

Eg. (task-1112-1.1-email verification completed ).

Project setup and Version control

1) Github Project Setup : We need to create directory with Product Name and version. Version
can be used if we upgraded our version and it will not be backward compatible and we want to
maintain it separately.

Yokart Example :
Yokart-V7 [Build with library version V1.0]
Yokart [Build with library version V2.0]

Yoyumm Example : project name should be like Yoyumm.

Note : If our new version is not backward compatible then we need to setup it separately.

2) Maintain Test release version : Can be a test/internal release. beneficial for

internal/external review and testing.

<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build Number>

TV : Testing version
Major Number : Major version of project
Minor Number : New feature/Module added
Revision Number : Any modification/bug-fixes done by team
Build Number : We can use this in case of testing release. It should be like YYYYMMDD.

Examples :

Step 1 : Suppose we have developed the project with one payment gateway(Paypal) and now
we want to release it for testing. Then testing release version should be like:

TV-1.0.0.20180425 [<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build

Number>]

Step 2: If some bugs fixed by us after reported by testing team and now releasing again for a
testing version. Then testing release version should be like:

TV-1.0.1.20180501 [<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build

Number>]

Step 3 : If we added one more payment gateway (stripe) Then testing release version should be
like:

TV-1.1.0.20180506 [<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build

Number>]

Step 4 : Fixed some bugs after reported by testing team. Then testing release version should
be like:

TV-1.1.1.20180512 [<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build

Number>]
Step 5 : Again fixed some bugs after reported by testing team. Then testing release version
should be like:

TV-1.1.2.20180515 [<TV>-<Major Number>.<Minor Number>.<Revision Number>. <Build

Number>]

3) Maintain Release version :

It should be a released branch.

<RV>-<Major Number>.<Minor Number>.<Revision Number>

RV : Release version
Major Number : Major version of project
Minor Number : New feature/Module added
Revision Number : Any modification/bug-fixes done by team

Step 1 : Now we need to make a release version (After test release version of TV-
1.1.2.20180515) as all of the work tested by testing team and working fine. Release version
should be like:

RV-1.0.0 [<RV>-<Major Number>.<Minor Number>.<Revision Number>]

Step 2 : Suppose we faced stripe payment gateway issue with released version RV-1.0. Then
follow testing release version as explained above and final release version will be like.

RV-1.0.1 [<RV>-<Major Number>.<Minor Number>.<Revision Number>]

Step 3 : If we added one more feature like banner module then it should be like :

RV-1.1.0 [<RV>-<Major Number>.<Minor Number>.<Revision Number>]

Step 4 : Now if our script had some drastic changes and it may or may not be backward
compatible. Then Major version should be change.

RV-2.0.0 [<RV>-<Major Number>.<Minor Number>.<Revision Number>]

Note: Later on we will provide a script to create db schema on every commit. It will be helpful
for us to track the work and we can switch to any version easily.