You’ve written code, you tested it and built it. Now, your release is ready to deploy into production.
But: is your production environment ready for the release? That’s a question every IT professional and platform engineer should be asking before accepting a new release — whether the release is an update of an existing app or a totally new deployment.
To that end, here’s a checklist to make sure that your production environment is ready to go. Obviously, your mileage will vary, and this list doesn’t address every aspect of every production environment in existence. But you can think of it as a starting point for designing a production environment review that ensures you…
So, let’s dive into the checklist to understand some things you should always review in production environments to improve release quality and cadence.
(For more dev resources, check out these DevOps conferences & must-read DevOps books.)
These are things that any production environment should be prepared for. To learn more, explore these release management best practices.
Before accepting a new release, you should have a clear understanding of the infrastructure that will support it. Whether your infrastructure is on-premises, hybrid, a single cloud or multiple clouds, you want to be able to:
How, specifically, is your application being released? Which tools are you using to deploy it? When should you expect the next release?
You can answer all of these questions by making sure you understand the delivery chain that is pushing the release out. Although the delivery chain is not part of your production environment per se, it plays a major role in ensuring that you can place applications into production successfully.
If your application consists of multiple services — as most do in cloud-native apps — you should understand how those services interact in order to compose the complete application.
Network mapping allows you to understand how your network or networks are configured. It’s particularly important in today’s world of complex, multi-layered, software-defined networks. Be sure that your network map both:
(Learn more about network operations.)
Although the nature and efficacy of firewalls for cloud-based workloads isn’t what it was in the days when everything ran on-premises, firewalls are still useful tools. Before deploying a new release, be sure that yours is working and configured properly.
Another basic requirement for a successful release is knowing which contractual requirements your production environment needs to be able to support. To be sure:
(Read about SLAs, SLIs and SLOs.)
What is your plan for backing up data or workloads and recovering them in the event of a failure? Your backup and recovery tools will vary widely depending on factors such as which type of infrastructure you use or what your recovery requirements are. Either way, make sure you have a backup and recovery plan in place.
In the event that something goes wrong (it will), you’ll need a plan that defines who does what, and tools to help coordinate those activities. Even the best-designed production environments sometimes suffer failures or disruptions, and a solid incident response plan is the difference between a mere hiccup and a total disaster.
(Explore common incident response metrics.)
Deploying applications successfully requires not just getting them into production but ensuring that they perform adequately once they are there.
How will you monitor for vulnerabilities or breaches in your production environment? Keep in mind that security monitoring is a multi-layered affair that should extend from application code to environment configurations to identity and access management and beyond.
Which remote access tools, if any, will you use to support your production workloads? Are they properly secured? Likewise, if you rely on physical access to manage the environment, is that access available and is it secure? You want to answer these questions before deploying a new release.
It’s easy for costs to spiral quickly due to unnecessary cloud resources left running or poor alignment between the type of cloud service you use and the workloads it hosts. Although ideally you’ve already thought about cost optimization before you deploy a new release, be sure that you have a plan in place for monitoring costs and identifying cost-optimization opportunities once your workload is running.
Your production environment will evolve over time. The infrastructure that hosts it, the configurations that govern it and the workloads deployed on it will change. For that reason, you should have a plan and process for accommodating future releases and needs, all while ensuring that your environment is able to adapt successfully as requirements change.
Successful future planning may be as simple as quarterly reviews. Often, a better approach is to build a continuous feedback channel that allows all stakeholders (developers, IT Ops and everyone in between) to communicate about upcoming changes or new requirements that will be placed on the production environment.
See an error or have a suggestion? Please let us know by emailing ssg-blogs@splunk.com.
This posting does not necessarily represent Splunk's position, strategies or opinion.
The Splunk platform removes the barriers between data and action, empowering observability, IT and security teams to ensure their organizations are secure, resilient and innovative.
Founded in 2003, Splunk is a global company — with over 7,500 employees, Splunkers have received over 1,020 patents to date and availability in 21 regions around the world — and offers an open, extensible data platform that supports shared data across any environment so that all teams in an organization can get end-to-end visibility, with context, for every interaction and business process. Build a strong data foundation with Splunk.