Dev Sprint - 02

[datakick]

I think you guys deserve to have a better visibility into how thirty bees development is going forward. So I decided to write bi-weekly sprint overview.

Let me start by explaining how we do development at thirty bees. We use scrum methodology, with 2 week sprints. In agile development, sprint is (usually) 2-week period of time when development team implements and delivers some functionality that has been agreed upon. Although we have a very small team (some naysayer would say it's not a team at all 🙂 ), we decided to practice this agile process for various reasons. One of them is to be more accountable and focused. Another is to have better understanding of how much work we can really deliver. 

Before every sprint, we have an internal scrum meeting where we decide on what will be implemented in the next 2 weeks. We have a huge backlog of items that can be done, with effort estimate. We also have a roadmap. We know when the next major version is going to be released, and what functionality it should/must contain (I will write a dedicated forum post about this soon for those interested). We use these information to select tasks for the sprint. 

We try to put tasks from different areas into to each sprint. The result contains tasks from these categories

• bug fixing -- we dedicate some time to fix bugs, maintain github, PR, etc
• enhancements that bring value to merchants -- these are standard enhancement requests, like multiple feature values or order editing
• platform enhancements -- these are enhancement that you guys don't know you need, but you will love them 🙂 Also tasks that will make platform more friendly and interesting to third party developers, theme developers, etc. 
• chores -- everyone hates doing chores (I know I do). But they need to be done. Tasks like server updates, implementing testing pipelines, support for php8, and what not. The platform would implode without regular maintenance.
• enhancements that bring value mostly to thirtybees org (us) -- we are adding some functionality to the core / modules that will make us happy. For example, we plan to add usage tracking (how many people installed tb, what features are they using, what errors did they encounter, etc). I understand that merchants don't care much about these (and some will not want to share these info with us), but we need to know. Otherwise tb company will fail, and tb platform will go with it
• support and paid tasks - time dedicated for paid support. Merchants can contact us and ask for some custom development, server migration, updates, etc. Currently our only stream of revenue.

OK, that's probably enough introduction. Let me present to you what we have done so far

Sprint 1

01/3/2021 - 16/3/2021

The first development sprint started when I finally joined thirty bees org full time at the beginning of this month. The goal of the sprint was to start progress, and to release first version. What we did:

• Translation handling - release prerequisites
  • temporarily remove php8-polyfill dependency -- tb failed on php 7.2 and newer because of it
  • Tool to extract translations - automated script that extracts translatable strings from core, themes, and modules
  • Tool to upload translations - script that uploads extracted translatable strings to crowdin, where you guys can translate them
  • Tool to download translations - script that downloads translations from crowin and prepares translation packs
• Tasks associated with releasing new version
  • Build and release all modules
  • Build and release core
  • Prepare translations
  • Release notes
  • Deploy to demo server
• Multiple php builds
  • Extending thirty bees build machinery to support building thirty bees for different php versions. We still support php 5.6, but this makes it very hard (nearly impossible) to maintain. It's because many php libraries that tb depends on are not supported on this php version, there can be composer dependencies conflicts, etc. 
  • Extend core updater to request specific php version -- work in progress
• Bug fixing
  • in first sprint we dedicated 1 day to github maintenance, fixing some bugs, merging some PR, and general backlog cleanup
• Support 
  • paid support requests 

Sprint 2 [current]

2021/03/17 - 2021/03/30

Plan:

• Core updater enhancements
  • Make core updater user friendly -- core updater was made by developers for developers, that's not good
  • support update to php version build
  • refactoring code to make it less dependent on tb core -- we plan to use the same module as a migration tool from ps16
  • various enhancements, like tracking specific revision
• Carrier price semantics
  • enhancement that allows merchant to enter shipping price with or without tax
  • this also fixes AEUC proportional issues
• Scheduled tasks
  • thirty bees will have build-in scheduler (cronjobs) to run scheduled tasks
  • we need this as a stepping stone to implement additional features, like maintanance tasks, automatic backups, automatic index regeneration, updates, tracking, etc
• ElasticSearch 
  • this module was originally implemented using crowdfunding, it was a shame it didn't work. We fixed that
  • review and extend existing PR requests for ES module, make it work with all supported elastic search versions
  • fixed various bugs
• PHP8 support
  • ongoing effort to make tb compatible with php8
  • in this sprint we renamed Attribute class, and all its usages in core.
  • This is work in progress, not in main branch, not yet available for general audience
• Support
  • paid support tasks
  • in this case, the result will make it to the core, as feature custom Permissions for back office controllers -- you will have an option to hide some tabs in Product back office edit page. For example, you can restrict translators employees to see and edit only Information and Seo tabs. Then won't be able to break your pricing
• Work queue
  • Work started on work queue feature
  • This is a mechanism that allow us to run some tasks in parallel / in separation from main execution thread
  • this will allow us to improve performance and to implement reliable long running tasks
  • example use cases
    • sending emails -- instead of sending email immediately/synchronously, we will create email task and push it to work queue. It will be send shortly by work queue worker. But it will not block main thread -- the server response will be much faster. Also, this allows for re-trying sending emails on error
• Bug fixing - Sprint 2

How is it going so far:

We are little bit behind the plan -- to implement Core Updater enhancement took much more time than originally estimated. However, we are almost on track. For those of you interested in burndown chart:

 

Sprint 2 will end today, and new Sprint 3 will start tomorrow morning. We have a sprint planning meeting today where we will finalise and agree on scope for the next sprint. I will create new forum thread containing plan for sprint 3 this evening, or tomorrow.

If you guys have any questions, don't hesitate to ask 🙂

Have a nice day all

[Lazar Marius]

Hi thank you for the sprint planning, it is great that you share this with us. Will the implementations be available on bleeding edge  channel ?

[datakick]

52 minutes ago, Lazar Marius said:

Will the implementations be available on bleeding edge  channel ?

Yes, most of it will.

The code is developed on different branches, and submitted to github already. Once it goes through automated testing, will be merged into main branch, and released to bleeding edge.

Not all, of course, for example php-8 compatibility work is very much work in progress, so this will not make it to the bleeding edge for a very long time. But it will, eventually.

[the.rampage.rado]

Bleeding edge is now called dev, right?

[toplakd]

Main branch is the most latest bleeding edge one can install through core updater.

Once installed, its identified as 1.3.0-main

Edited March 31, 2021 by toplakd

[the.rampage.rado]

Thanks!

[SLiCK_303]

On 3/31/2021 at 1:12 PM, toplakd said:

Main branch is the most latest bleeding edge one can install through core updater.

Once installed, its identified as 1.3.0-main

so whats the difference between 'main' and 1.2.x'?

[datakick]

Current version is 1.2.0, next major version is 1.3.0, next bugfix version is 1.2.1.

• main branch represents future major release 1.3.0. This is the real bleeding edge, it contains all the feature work and bug fixes
• 1.2.x represents future 1.2.1 release. It contains only a handful of commits that fixes serious issues.

I would like to release bufixes releases every 4-6 weeks, so there's probably not a good reason to regularly update to 1.2.x., you should just wait for 1.2.1.

Currently I'm finishing redesign of core updater that will hide this complexity. You will be able to choose if you want to keep your store updated to latest stable version, or to bleeding edge. And Core updater will tell you when there is something to update.