This article was also featured in Built In.
This month, Built In Seattle spoke with Bryan Yamanaka, our director of engineering, to learn about staging environment best practices at Zipwhip.
What’s a critical best practice your team follows when developing staging environments?
All of our staging environments are built using automation and infrastructure as code practices. This makes it more efficient to build these environments and ensures the configuration is consistent every time we deploy. It also gives us assurance that the staging environment is nearly identical to production.
Data privacy is protected by filtering sensitive data when seeding databases for testing in the staging environment. Staging environments are treated the same as production, where issues are treated as incidents and on-call engineers are paged to fix the problem.
What processes does your team have in place for monitoring and/or maintaining your staging environment?
Monitoring configurations are similar to the production environment for all infrastructure, services and code deployed to the staging environment. Zipwhip also employs on-call engineers to troubleshoot and resolve issues so code can be tested and promoted to the production platform. These are important so we don’t impede the flow of value being delivered to customers.
What’s a common mistake engineering teams make when it comes to staging environments?
Relaxing security and discipline in lower-level environments is a common mistake. Oftentimes, these mistakes lead to instability in the environment or live site incidents due to lack of testing. However, cutting corners and not adhering to security and configuration best practices can also amount to data breaches and loss of customer trust in your product. To avoid these mistakes, we ensure our staging environment follows production configuration and deployment best practices.