I can&#x27;t seem to get into the game of fully automated deployments to production. It definitely interests me but a few things always hold me back.<p>The first issue is that I&#x27;ve probably set up 10 or 15 app development and deployment &quot;systems&quot; if you will. I&#x27;ve found that it&#x27;s very beneficial to automate the simple stuff but it quickly reaches a point of diminishing returns. A super-custom system always works great for a while until some big change or library upgrade or refactor or whatever comes down the pipe. Then we spend a ton of time resetting up everything. We have to keep the build system components up to date so it doesn&#x27;t turn into an ancient mystery box. Sometimes an upgrade breaks the whole thing and then we&#x27;re on stack exchange all day debugging a parser library or some other thing that we don&#x27;t care about. Basically spending hours and days and weeks on the build system so we can have that sweet one-click (or fully automated) deploy.<p>The other thing is that we release frequently but we tend to double check everything before it goes to production. Our staging server is auto-deployed except DB changes which we do manually. Right now it&#x27;s about 2-3 clicks for us to deploy to production and it works fine. We still do DB changes manually though. It takes a minute or two to deploy. I feel like the process encourages that final check that everything is cool.<p>I guess I&#x27;m nervous to set up something that deploys to production simply by adding a tag to a slack message or the git commit message. Should I get over myself? If I change my thinking is it possible that deployment to prod could be a non-event?