The Essential Developer Environments
|
As a solo Developer it’s easy to break the rules and just push code straight to PROD (production). Although, as your code starts to mature and user base grows you’ll want to perform some ‘sanity’ checks prior to just dropping a new build on the prod server. I’ve met tons of developers at various stages of their careers who have all admitted to making changes on a production server. Whether insignificant or major. So, just to paint the picture for individuals who are new to Software – making changes to an application in Production is like running a play in the Super Bowl that has never been practiced before – you just don’t do it. Unless, your Super Bowl is an audience of 1. To knock out the first question…
Not only is it risky, but it builds bad habits. No matter how big your codebase is, how large of a user base you have, or how small the change is; it should go through some channels which allows you to evaluate, test, and ensure that you are not going to break anything. As Software Engineers, the worst thing we can do is prematurely push code to a Production Server without performing due diligence and quality assurance. It allows our work to be challenged, produces doubt in your stakeholders, and deteriorates relationships with the users of applications. When a Software Engineer, even as a one-man show, produces an application for deployment, he should be certain that Production server configurations are set up properly to support and run the application. Much of the work that a Software Engineer does is around testing, so making changes either in Production or without some isolated setting to confirm all is working becomes a recipe for disaster. So, at a minimal I recommend 3 environments. Local – Where the software engineer builds and develops software. Staging – Where software engineer promotes code once it is complete and ready for review, testing, and demo to stakeholders. Production – where the final version of the code is deployed to for usage by the mainstream users. Let’s dig deeper into these environments… Your local environment is where you do your work. I strongly recommend, having a local database, and the ability to run all services locally on your machine as it will replicate having your own server. Once you have completed testing of your application or new feature, you then should promote the code to a Staging server. This server serves as an environment that is, virtually, identical to your Production server. Often times, Staging is where the most strenuous testing occurs, whether automation, load balancing, or security scans. This takes place to simulate what users may do, understand how the application is performing, and ensure the application is in align with security standards. Another note about your Lower Level Environments (LLEs), is they should have restricted access, and only be available to internal users so that web crawlers do not accidentally discover your application in a testing environment – this can be very chaotic if not followed. On that note, I’ll mention an additional environment outside of Prod, Staging, and Local which is Dev/QA/Testing. This environment, in many instances, is designed for early test. As software teams make changes rapidly, the need to ensure that their changes are in alignment with others without compromising a Prod or even Prod-like environment. It serves as an environment that can be modified, which may make it out of sync with Production. This allows for QA, UAT, and other stakeholders to spend more time with the code prior to it migrating the release to Staging. Staging is usually just a dress rehearsal prior to going to Prod, and code is intended to only stay there at a minimal amount of time before being promoted to Prod. In a later post, I’ll talk some of the Industry Best Practices and common terminology and lingo.  |