It seems weird that I even need to write this blog post, but too many times this issue has come up when we have: worked with other Adobe Experience Manager development teams, taken over projects for other AEM development teams, had sales calls with potential customers who already have Adobe Experience Manager, or learned that our own teams were doing this. Why are people working directly inside CRXDE on their Adobe Experience Manager Production environment? And lest you think this is only about development, this has taken the form of authoring as well.
It’s true that when a developer is in the middle of their development cycle that it is frankly faster and easier to be in CRXDE manipulating the code rather than going through a build process. You get to see your result much faster. It’s totally ok. But this should only be done through a Dev lane. Stage and Production should only get code via an automated deployment process or manually through the Package Manager.
I remember a T-shirt that a friend used to wear: “I don’t always test my code, but when I do, it’s in production.” It’s funny because it’s ridiculous (no self-respecting developer would do that) and because somewhere deep down where we don’t want to talk about it, we’ve all done it. We’ve all done it!
There is something fundamentally wrong with your implementation and process if you find yourself going into CRXDE on a regular basis, either to manipulate content or to modify code. I am reminded of a customer who explained the process of updating some piece of content. I was a little shocked when he casually told me that he went into CRXDE to change the address and phone number. I was even more shocked when I learned that the reason he did it is because there was no authoring interface for him to do it! That’s just sloppy/lazy development. Now, before we get too high on our soapbox, I don’t know what constraints the developer was given. Maybe the customer was out of money and there wasn’t any other choice. Or maybe it was another reason completely. It’s still a bad thing to do.
One of my early AEM projects provides another example. Occasionally the customer would need to change the publish time of an article, but the only way to do it was for me to go and modify the epoch within CRXDE because there was no authoring interface. Shocking, I know, from someone writing a post demonizing those who don’t architect appropriate solutions. Didn’t we always do things perfectly? I guess not. In our case, we just didn’t plan for it, because we didn’t know there would be a business case around that.
But let’s stop giving excuses. It’s not what should be done. We all know it. Don’t architect solutions that force authors to work on content in CRXDE. And, don’t manually make changes to code in CRXDE on Production. Just stop doing it. End of line.