In a product-driven software development environment, how are you accounting for and managing the depreciation of your internally developed software assets, especially considering the rapid iteration cycles and continuous delivery models prevalent today?

What Warren Welnmeyer said is pretty accurate. Especially for software. You may have a few COTS products you bought, that you can add to your depreciation schedule, but in today's world, there are more likely to be services, or ongoing software leasing that is more of a subscription model. In these cases you can't depreciate that. 

In the case of internally developed software, that is pretty much a sunk cost. Because the cost you paid was in salaries or labor contracts, you can't depreciate that. Additionally, you can think of depreciable assets as things someone could have if they bought the company. If you sold off all of the company assets, you can't sell your software because it is likely very bespoke. Even a COTS product you purchased, or leased likely has a non-transferable license. 

Now, I'm not a finance expert so I'm happy for someone to correct me but I'm reasonably sure that's the case. Especially with internally developed products. Rapid software iteration cycles is just how you do it. You could maybe consider it R&D budget but you can't depreciate it. 

The idea of "depreciation" with regard to software assets is not really a good fit: you should be thinking instead from an application lifecycle management perspective.

That is, a software asset is maintained and upgraded throughout its lifecycle until there business case for continuing to do so no longer exists. Possible reasons for a business case no longer providing adequate justification include:
  - the provided functionality is better provided by another software asset
  - the ability to continue to maintain and enhance the software is no longer feasible (for example, the software is pinned to a specific operating system version or obsolete hardware, or the foundational architecture of the software can no longer scale to support capacity/reliability requirements)
  - the business direction has changed and the capabilities of the IT landscape must change with it
  - etc.

However, managing the software lifecycle is necessary, but not sufficient. If the software asset in question is an application, it should be strategically governed as an investment asset: this means actively assessing its investment value regularly (especially when business strategy is reviewed or adjusted) to not only validate that the application is worth continuing to invest in at all, but how much investment it is worth (for example, is it worth keeping if it only requires a minor investment such as re-platforming it? Is it still worth it if it has to be substantially re-written? etc.) 

Establishing the value of an application consists of two main, inter-acting dimensions: its Business value and its Technical value: the combination of these two value inputs results in an "investment" value and a resulting "investment disposition" decision (eg., improvement, rationalization, etc.).

Application Portfolio Management (not to be confused with Asset Performance Management!) provides a cross-industry best practice for implementing the type of asset lifecycle and investment governance you are asking about.