Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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 :
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.
Yokart Example :
Yokart-V7 [Build with library version V1.0]
Yokart [Build with library version V2.0]
Note : If our new version is not backward compatible then we need to setup it separately.
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:
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:
Step 3 : If we added one more payment gateway (stripe) Then testing release version should be
like:
Step 4 : Fixed some bugs after reported by testing team. Then testing release version should
be like:
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:
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.
Step 3 : If we added one more feature like banner module then it should be like :
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.
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.