An alter procedure would not normally be replicated and so would not cause any problems. More than likely you're doing DDL operations and changing the tables and this is breaking the replication.
Michael Keleher has suggested your replication may not be set up to replicate schema changes:
Open the properties of the publication, go to the Subscription Options section and change the Replicate schema changes property to true. Then all DDL changes applied to articles in the publication will be applied to the subscriber without the need to re-initialize.
If that works for you then great.
In my experience replication can cause a lot of normally benign deployments to fail, and so I prefer that replication be removed as part of a deployment and reapplied afterwards.
For a "lighter" touch, in your specific example the end of your deployment you can mark the subscribers as needing a snapshot (using sp_reinitpullsubscription) then trigger the snapshot agent (with sp_start_job).
It's roughly documented in BOL https://msdn.microsoft.com/en-AU/library/ms152466.aspx?f=255&MSPPError=-2147217396 though the instructions differ slightly depending on whether you're doing push or pull subscriptions.
However you probably need to dig a little more into what's actually going on to cause the problem because doing this kind of thing will make every single deployment go slowly for little reason.