Why a process is launched itself automatically after a deployment?

For ALL of my scheduled processes, I use a boolean constant in the timer conditions, where the process will only fire if the constant is set to true.  Deploy the process to production along with the constant set as false, then you can flip the constant back to true after deployment has completed, which will cause the process to not run during deployment, but run as scheduled in the future. 

This is also handy for situations where you may want to turn the process off later, especially temporarily.

To clarify, do you just set up a separate constant for each such process?  I can see advantages to that approach as well as the approach wherein there's a shared constant for all timed processes (or certain groups thereof) in the environment.  Generally I've been too lazy to retrofit my system's timed processes with these, and/or haven't managed to compromise on a single unified approach.

FWIW, In the past I've set up conditions where the hour has to match the timer's launch hour, but that can be a giant pain to actually test (and ensure there aren't timezone conversion mismatches that've snuck into the equation, etc).  I think, in general, I might like your suggestion more.

I setup one constant per scheduled process model, always a 1 to 1 ratio.  That has worked best for me as it's typically one at a time where I'm turning on or off, and this ensures a release to production isn't toggling a constant that affects other processes which could be starting around the same time.  

I have some groups of processes that are held or released based on constants also, but generally not for scheduled activities.  Most common is with integrations with other systems, where we have some databases that request us to 'hold' interactions (writes) at certain times (where the DB is still up), or the DB may be down for maintenance or unexpectedly.  If something occurs, I flip the constant to hold integrations which also flags sections on related forms to alert users that their transactions will be held temporarily.  This is also a work-around for the Write to DS nodes not having the "Pause on Error" setting as the Query DB node does, so the process can pause and release gracefully based on the constant value instead of throwing an error due to an offline connection (..resisting the urge to tag Peter to check on that enhancement request ).

I've done some things in the past with checking the current time and using logic to hold or fire the process based on that, but as you mention that becomes a pain quickly when you need to start a process later after a failure, or adjust the schedule, or for testing, etc.  I've nixed that approach altogether. 

For constant settings that can change regularly (or for scheduled processes with frequent updates), I even have a process built out where I can manage them from my "COE Admin Console" rather than from /design.  Update Constant service to the rescue!  

I setup one constant per scheduled process model, always a 1 to 1 ratio.  That has worked best for me as it's typically one at a time where I'm turning on or off, and this ensures a release to production isn't toggling a constant that affects other processes which could be starting around the same time.  

I have some groups of processes that are held or released based on constants also, but generally not for scheduled activities.  Most common is with integrations with other systems, where we have some databases that request us to 'hold' interactions (writes) at certain times (where the DB is still up), or the DB may be down for maintenance or unexpectedly.  If something occurs, I flip the constant to hold integrations which also flags sections on related forms to alert users that their transactions will be held temporarily.  This is also a work-around for the Write to DS nodes not having the "Pause on Error" setting as the Query DB node does, so the process can pause and release gracefully based on the constant value instead of throwing an error due to an offline connection (..resisting the urge to tag Peter to check on that enhancement request ).

I've done some things in the past with checking the current time and using logic to hold or fire the process based on that, but as you mention that becomes a pain quickly when you need to start a process later after a failure, or adjust the schedule, or for testing, etc.  I've nixed that approach altogether. 

For constant settings that can change regularly (or for scheduled processes with frequent updates), I even have a process built out where I can manage them from my "COE Admin Console" rather than from /design.  Update Constant service to the rescue!