Deploying software is a notoriously risky portion of the software development lifecycle. Our industry is littered with stories of ill-conceived deployments that caused huge headaches to deal with and correct.
As developers who enjoy the creative output of programming, it’s easy to neglect the operational details of deployments despite the fact that it’s widely believed that simple deployment processes make for happier developers.
At Contactually, investing even a small amount of time to develop fairly simple deployment scripts has paid off huge dividends.
Let’s look at what we wanted to accomplish with our deploy scripts, how our scripts do this, and what benefits this has provided our development team with.
The Goal of our Deployment Scripts
We want to have deployment scripts for all major components of our application/infrastructure. In our case:
- A ReactJS frontend hosted on Amazon S3
- A Ruby on Rails backend deployed on Heroku
We want to handle deployments of our components to all possible environments. In our case:
We want to use minimal setup on behalf of the developer, and use existing credentials and permissions to perform deployment actions.
What our Deployment Scripts Do
We have one deploy script for each of our main repos: our Rails backend and our React frontend.
These two scripts have minor variations, but roughly execute the same steps. Some of the steps executed by the scripts are contained in their own bash scripts or rake files.
Pre-deployment CLI checks & confirmations
First, our scripts run through a series of automatic checks, or forced developer confirmations to help prevent against ill-advised deployments.
- Confirm which branch you are deploying to which environment
- Confirm continuous integration specs are passing
- Check git branch takes the form of “release/<version>”
- Confirm user awareness of any data migrations that need to be run
- Confirm whether to use Heroku Preboot in case of migrations
Next, our scripts notify slack channels that [developer] is deploying [release] to [env].
The actual deployment is not that complicated, and mainly involves compilation, pushing or hosting files, and turning over servers.
- Bundler or Webpack compile assets
For the frontend:
- Upload assets to s3
For the backend:
- Push release branch to Heroku
- Run Rails migrations
- Restart Heroku workers
After deploying, we notify slack channels that [developer] deployed [release] to [env], with relevant included commits and JIRA tickets listed for the sake of awareness.
To save developers from manually keeping JIRA up-to-date our scripts then label and transition tickets involved in the release.
For staging deploys:
- Prompt the developer if each Pre-Release-Candidate (column) JIRA ticket is included the release [y/n]
- Apply a label for the release version to included JIRA tickets
- Transition included JIRA tickets to a Staging/QA column
For production deploys:
- Close JIRA tickets labeled with the release version
Git book-keeping (for production deploys)
- Apply a tag to the git branch, annotate with developer and timestamp
- Merge release branch changes to master and develop
- Destroy remote and local release branches
Clear Conceptual Benefits
With these deployment scripts in place, there are three thematic ways that this has made life easier on the development team.
Branch names, release tags, JIRA tickets, migrations are always handled in a consistent manner — buying the development team ease-of-mind.
Having the deploying developer prompted with a set of gut-check questions ensures that no one should be deploying without skipping a step, forgetting about a test, etc.
Public deployment notifications help promote team awareness and avoid miscommunication about timing or dependencies involved in builds.
Not worrying about deployment details means less mental overhead spent by developers. This helps productivity, stress levels, and team trust.
Subtle Practical Benefits
When deployment is consistent, safe, and simple a whole slew of practical benefits are naturally realized
- A developer can deploy code their second day on the job
- A developer having an off-day is insulated against deployment mistakes
- Many deployments per day does not cause operational complexity
- Deploying early in the morning or late at night is less worrisome
- Developers can multi-task and save time while while deploying
- Tracking regressions over time/deployments becomes easier
If you asked developers to describe hypothetical traits of development teams they would like to work on, many of the above traits might be described.
And so, when given the chance to add those capabilities for one or two hundred lines of bash or ruby, the choice should be a no-brainer.
For millions of professionals, relationships are the backbone of a viable business. Whether you’re working with clients, prospects, or potential investors, Contactually helps you build stronger relationships with the people who can make you successful.
Empowering Developers with Consistent, Safe, and Simple Deploy Scripts was originally published in Contactually Product and Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.
Latest posts by Troy Crosby (see all)
- 5 Aspects of Rapid Feature Validation & Iteration - May 17, 2017
- Empowering Developers with Consistent, Safe, and Simple Deploy Scripts - April 25, 2017