How to cope with SQL Server 2012 vs SQL (Azure) Database sql files
Rather than maintaining two separate code bases, the easier way to do this is by aiming for the lowest common denominator. Try to only use features in the database that are supported in Azure SQL DB. That way you'll have a single code base that works for both, and you'll have much easier upgrades, too.

For box-product customers that truly need SQL Server features that aren't available in Azure SQL DB, build a separate set of scripts that are deployed after the database is created.

If there are specific features you need in SQL 2012 that aren't available in Azure SQL DB, try posting separate questions about each of those (or list 'em in the question itself) so we can get a better feel for why you really need two separate code bases.