When Dev Isn’t Like Prod, Nothing Works as It Should

When Dev Isn’t Like Prod, Nothing Works as It Should

Look, maybe this isn’t something I have to tell you, 'cause it might sound obvious. But honestly, I feel like I gotta say it. We just went through it recently, and it wasn’t easy at all. It had consequences. So I’d rather you don’t make the same mistake we did.

Let’s get into it.

So, we’ve got an e-commerce site running in production. It’s been live for like... I don’t know, 3 months already? Things are going more or less fine. Yeah, of course there are the usual day-to-day issues. Some architecture problems showed up late in the game and are a bit expensive to fix, but hey, that’s expected.

Besides all that, we’re still building stuff. The project keeps growing, getting better, and we’re adding features that weren’t strictly needed for the go-live.

Now here’s the thing.

We’ve got a release process set up with our client. Every Tuesday, we push to production all the tasks that were finished the previous week. We commit to having all our stuff integrated into development by Friday morning. Then, the deployment usually happens Tuesday at noon.

The client has a couple of days to test things in development before the release goes live. If they don’t give the green light, then nothing goes up to staging or prod.

This week, Tuesday comes, and we had to ask if the release was going ahead as planned. They tell us they’re having trouble testing some stuff. Hours go by, we ask again, and it turns out one of the things we built connects with a third-party app (also from the client, handled by another vendor). Not part of the SFCC platform, that’s our turf, but another system we’re integrating with.

And guess what? Something in that other system wasn’t working properly. Which meant they couldn’t test the feature. Even tho what we built didn’t really touch that system directly. Like, no changes on our side that should’ve affected it.

The vendor for that platform? They were just dodging the issue. “Everything’s fine,” “nothing wrong here,” bla bla. Bottom line: no release on Tuesday.

Wednesday morning comes. Still waiting for the go. Same story. The other partner hadn’t fixed the problem.

Wanna know what the real issue was? Their development environment wasn’t aligned with production. Not just the configs, even the processes were off. Which is a big no-no.

What does that mean? Well, when you’ve got a dev env, it’s supposed to behave just like production, right? Ok sure, it won’t have the same amount of data, but the behavior should match. And when you’re connecting that dev env to other systems, those systems also need to act like real production systems.

But these guys had some features switched off in dev. Stuff they thought used too many resources or whatever. Thing is, the client didn’t know. So they couldn’t test properly. Boom. Delay.

So yeah. We’ll try again tomorrow… I mean, the next day. Hopefully we can still deploy this week. If not, we’ll have to wait till next week and bundle this release with the next one.

Moral of the story? Always align your dev environments. Make sure they behave exactly like production. Or stuff like this happens. Every. Damn. Time.

← All blog posts

Bad Data Travels Fast in SFCC. Validate It Before It Spreads

Data purging in SFCC is not housekeeping. It is architecture.

SFCC Integrations: The Endpoint Working Is Not Enough