Does WordPress have a grudge against continuous integration?

First off, I have many years of experience with WordPress and am a polyglot that works in multiple environments, with multiple different patterns for continuous integration and dev ops. WordPress is, and always has been, one of the worst platform for real-world development and maintaining any kind of consistency in migrations. WordPress is a development anti-pattern by design. I’m not alone in this, as there are countless developers (people who aren’t premium theme and plugin developers) who flat out refuse to use or develop on WordPress for this very reason. I’m a bit more optimistic, but when it comes to the following scenario, I hit a brick wall at every turn and fail to see any kind of tangible solution. Maybe you can shed some light on the situation.

Let’s consider this scenario:

Client with active and busy website requires a complete overhaul of a WordPress installation with new theme and different plugin requirements. The development project isn’t something that can be completed overnight, certainly not something that can be *gasp* developed remotely, requires database changes in development and publishing on site cannot be halted for months during the development process (period).

Problem

ID Collisions. Custom fields, new pages, new content types and their objects: all of these will utilize the wp_posts table, and increment an ID. However, on the production site, the ID will increment as well, causing collisions when attempting to migrate the content updates and requiring very tedious, error prone and potentially installation-breaking modifications to associations (for example: terms).

Anti-pattern workarounds

• Just halt all publishing No.
• Modify the auto-increment value in the database on either the development/production database and deal with it later No. This presents serious issues when attempting to import posts/terms/etc and can cause pretty big issues with the health of the database
• Don’t change the posts table in any way Working around this is near impossible based on the requirements. At no point in time should a platform prevent or restrict development, this in itself is an anti-pattern.
• Manually change hundreds of post ids and associations on either the development rows or the production rows for which collisions occur while demanding a “grace period” on production. This was definitely the original plan. However, if you are suggesting this, I ask myself if you have ever developed for anything other than WordPress. The potential for breaking something through human error or missing a field is incredibly high, it’s more fragile than a 1mm piece of glass. Additionally, the grace period required for testing these modifications due to the fragility is ridiculously high.
• Update the development database before development Sure, that would work if the site wasn’t being added to, and modified on a minute-to-minute basis. By the time the data is migrated and the change is applied to development, the auto-increment ID has already increased on the production server.
• Conduct database-altering modifications on the production server This just makes me want to spend a day finding memes and spamming Matt Mullenweg’s phone for a few months.
• Learn Magic Willing to learn, please teach me.

The above solutions are all I can think of, it’s very possible that the head-banging has left me with a narrow perspective that has subsequently limited me from seeing a creative-solution outside of the confines of my frustration with the myopic design of WordPress. I am more than willing to accept I”m wrong and that there is a known pattern for addressing this issue, and so I graciously accept your rebuttals. But please, no crappy workarounds, or suggestions that in no way contribute to actually solving this real world problem.

While banging my head against the wall real platform solutions (not myopic anti-patterns) arise that solve this and actually enable the development of WordPress migration tools, developer resources and attract quality development as opposed to get-rich-quick scheming development.

• GUUID Hashes instead of auto-increment for IDs Other than providing security by design for e-commerce solutions and membership sites through obscurity (almost always the first step for security), this change would completely sideline all the design faults of WordPress with regards to continuous integration and data migrations, and doesn’t require any serious redevelopment. Yes, this increases query overhead quite a bit, but with some relational tables for revisions and native object caching sans plugins this problem is a moot point. This simple change to WP architecture completely eliminates the countless problems of data issues in WordPress development, forevermore.
• Completely unrelated, but for the love of all that is beautiful and good in the world use GIT or Mercurial instead of SVN, and don’t publicly punish those who mirror onto GIT. It’s 2017. smh.

After this multi-day search for any sort of sound logic backing the continuous integration considerations, or lack thereof in WordPress, my only conclusion is that the WordPress team hates continuous integration and are masochists or CI is a concept they feverishly disdain.

The only solution I’ve found so far is to say goodbye to WordPress forever and to suggest migration to a platform that actually considers real-world development and doesn’t allow architectural design to reflect in the database ever. I’m trying to find every way possible to prevent this.

Aside: Why did WordPress in the platform wars? I’ll never understand how the network effect benefitted WordPress, but I have no choice but to bow to its supremacy.