Over the years I’ve been working on a dozen SAP Commerce implementations in every variant you can think of; From developer to architect, from B2C’s to B2B’s to B2B2C’s, small and modest to multi-site/multi-store, internal and external projects..
With so much water that ran under the bridge you start identifying patterns that repeats over and over, or as I will call them “symptoms” that a project is suffering or in bad shape, they feel like déjà vu.
The following are some of those symptoms that I’ve identified over time that show your project is drifting away from shore or already in treacherous waters 🌊.
Every deployment comes with a handful of bugs and regressions
E-commerce never stops evolving, new and important features are pushed (sometimes in a rush) all time time, a payment platform, the new and shiny CRM integration, etc..
And with a deployment.. bugs 🐛 and regressions, things that use to work now they don’t. So the new sprint has to accommodate bug fixes, over time those bugs use 20, 30, 40% of the allocated time. Client is pissed, dev’s are worn out.. it’s just a matter of time.. this is a ticking bomb 💣
This is not only applicable to SAP Commerce implementations but any software development project. This usually happens when there is a lack of testing (unit testing, regression testing or TDD), no code reviews, no top down oversight on development. So, what can you do about it?
Regressions and bugs are a symptom of absence of quality assurance and overall code quality of a project
If you are in a bad spot (not even the basics) start with creating automated regression testing for critical parts of the e-commerce, since now OCC and Spartacus are the way to go tools like Tavern 🍺 are easy to learn and deploy. From that spot set the grounds on how to improve your internal process leveraging as much as you can on automation.
I’ll chip in two more tips:
- your pipelines should check for code quality and initialization errors, you can kill 2 birds with one stone (passing SAP CRC’s) setting it up with sonarqube integration
- every pull request should be reviewed (for real) and approved by the team lead or architect
Broken initialization process
A new dev joins the team, pulls the code, compiles it, ant initialize and then.. Errors.. a lot of them, items that can’t be resolved, non-stoping exceptions, it takes ages to finish.. to what end? an environment that barely resembles an e-commerce. I’ve seen this SO MANY TIMES.
This is common in projects with many years on their back that had some rough times from time to time, eventually data maintenance is put on a side..
When your project is on this state you are unable to test basic functionalities because of the missing data and everyone that joins the team is going to trip over the same stone: “fixing the local environment”.
The amount time that is lost can be astonishing with an evolving team over a long period of time.
A broken initialization process is a symptom of a project lack of maintenance
This can be approached in several ways:
- add to your pipelines an initialization check for every merge request, if there is any error mark it as ⚠️ failed. No FIX, No Merge. 😐
- if you are using patches (and you should!) for your deployments, you can reuse them as a way to maintain your environment with up to date data.
Also, initialization errors are one of the checks in SAP CRC’s for deploying the project on CCV2 or in any audit they perform. Better have it under control 😉
OH! And setting up a local environment should take at most 1 hour from pulling the repository to finishing an initialization process with an easy to follow step by step guide on the README.md file.
The repository is a mess
I recently landed on project from a Fortune Global 500 company that had more than 6+ years of development, multiple teams all around the world and a constant stream of new features.
Complexity was A++, but repository management was non-existent. It had thousands of branches (nothing was ever removed), most of them dead or already merged. GUIs like Fork ❤️, Gitkraken or SourceTree will eventually crash trying to draw the history graph.
It looked something like this.. and good look to you trying to figure something out.
I know.. everyone has his preferences on how to work on his own task. A team has developers that commit a new change every 5 minutes and others that commit once and create a PR with 1000 changes to review 🤦. In the end everyone using the same repository and trying to maintain some order is a challenge.
Your repository being a mess is a symptom that there is a lack of project oversight and task follow up by the project leads
For reasons like this and to achieve a clean and easy to follow project history I ask my team to use ForkFlow with the main repo only containing a few branches: dev, release and main (sometimes a big feature or the current sprint). For some of you, specially if you work on open source projects making this recommendation will seem obvious, trust me, this is “the exception rather than the rule”.
Key business processes can’t be replicated or tested on a local environment
This type of exchange is not uncommon
— ”There is a critical issue on the project!! Can you please take a look?”
— “Sure, let me pull the repo and check on what could be the issue”
— “Oh, but you can’t make orders on your dev environment since you need to simulate it with the ERP that can’t be accessed from our network.. and the products that have issues are not present in local data.. and ..”
— ¿Hmm?
— “Oh, and there is no APM on the customer environments. Can I have an ETA on this?” 💀 R.I.P.
Every process in your e-commerce should work in a local environment, specially if is a key functionality related to the Cart, Orders, Checkout, Accounts or Search.
A key process that can’t be easily tested is a symptom that you are open to critical issues from unforeseen events
Every extra step a developer has to take to check on any issue, to test some case, to verify something is time lost that you can’t recover. Those manual steps you and your team are performing over and over is 💸 💸 down the 🚽. Fix it!
Wrap up
Testing is a big part of any development process, work on it, automate it. Fix the initialization process, on-boarding of new devs will be smooother 😎. Have quality data in your local environment, your future self will thank you. Push to have all integrations accessible and easy to be tested, you don’t want to guess what could be the issue when a problem arises.
Now a question for you 🙂 What are others symptoms you can think of that hinder your project?
Cheers! 🍻
Nico.
