Jump to content

Prestashop: Development process life cycle & Continuous Integration (CI) & Version control (VC) - ATS RECOMMENDATION

Recommended Posts

I would like to recommend the great team of PrestaShop a way to manage and maintain the iterative development life cycle-using proven development methodology. This is a piece of blog info that can be found on my own blog soon.

I have been following PrestaShop since version 1.1.x.x I love the modular design and architecture of PrestaShop and have started using it as basis for part of my new concept business concept, but i notice some inconsistent and instability in your development life cycle approach and would like to contribute to improve that. I will introduce a practical (agile) way to implement the development life cycle so that you can deliver better quality work (i.e. previous new updates and releases shouldn't bring OLD errors!!)

In my experience for example in version 1.1.x.x my e-mail worked, now in version 1.2.4 it doesn't! This shouldn't be happening. So hopefully this piece of suggestion can improve your work quality which will make many of your users happy. I guess that is what we all want.

The situation:
It seems like new updates and or releases breaks old 'code'. This is not a good way to develop software.

The suggestion - the agile way from now on
1. After you think a certain version is ready FREEZE IT, so that your developers cannot edit and or update the working version so far again (u can achieve that by enabling the developers to branch from the development tree and continue work in the new branch (or other way around). This way you will be avoiding the danger of breaking previously working and tested code.

2. Allow ONLY a separate person or team (MUST be different developer(s) than the one who coded the to be added and or to be merged code) verify, validate and test new improvements and or features before you merge and or add it with previous working version. This way you will not enter the situation where by a developer review his or her own code. This is just a good practice. I never review my own code in a 'frozen code', i do that before i forward it to be merge with the 'frozen' code.

3. After successful testing you increase the previous versions version number with one and then merge and or add the new features and or improvements. This way you will see that previous code will not break, while adding and or improving (new) features (code). This is called continuous integration (CI) using a test driven development approach (TDD), in execution you can use eXtreme Programming (XP).

4. Release new software

5. Repeat steps one (1) to five (5).

**This is just a quick summary intro to The development life cycle: (H2) The setup - version control and continuous integration. * this is a e-book which I will be launching soon on how to improve development processes to deliver quality and robust software.

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.