In theory, this layer magically removes the headache of individual developers struggling to configure local environments and guarantees environmental parity but in practice, it can stall progress. Adding a configuration management layer should not be taken lightly because it adds an additional layer to manage and maintain.
#VAGRANT ANSIBLE MANUAL#
And even when we do, the project’s scale, scope, and budget could necessitate a more manual approach. Of course, we don’t live in a perfect world, nor do we always have the luxury of planning a project from its inception. In Figure 2, configuration changes have to be described only once, and the actual work of implementing and deploying them across environments is automated.
#VAGRANT ANSIBLE SOFTWARE#
The discoloration in Figure 1’s software logos is meant to indicate the drift and version mismatch that often creeps in when these changes are manually configured. In Figure 1, every time there is a change to the development stack, each of the development, staging, and production environments must be manually updated. In a perfect world, this means a shift from the workflow depicted in Figure 1 to the workflow depicted in Figure 2.
#VAGRANT ANSIBLE CODE#
Infrastructure as Code allows us to inject the benefits of our software development workflows - version control, code reviews, and automated deployments - into our IT operations tasks. We’ve been using configuration management tools for years and have worked with clients who have embraced Infrastructure as Code from the start - Hootsuite, for instance - as well as clients who have adopted it after launch. In short, it was time to add configuration management tools so that we could manage our Infrastructure as Code (more on these buzzwords later). Further, we needed to onboard new developers quickly so that tasking them with a few hours of work did not require us to absorb several hours of setup time. Put together, this meant that we needed up-to-date replicas of production locally and on staging, and we needed an ongoing system to keep these environments in sync. Further, given the increasing complexity of FindaTopDoc’s codebase, coupled with their ever-growing audience, we reached a point where we could no longer reliably test our work without mirroring the entire production stack on our local and staging servers. As their core technical partner, we’ve committed to providing elastic development capacity to help implement their vision this means that we need to quickly ramp up or down on development in response to their needs. This growth has not happened in a vacuum: has been producing quality content consistently, and aggressively developing new features. We recently went through this with a client whose site has experienced explosive growth over the past year, generating nearly 10 times the traffic it was experiencing just 12 months ago. But as the scope of the project grows, for instance with caching or proxy layers, it often makes sense to implement better development, staging, and production parity. In this case, it often makes sense to forgo provisioning a dedicated development virtual machine (VM) or staging server, and instead, to use generic or shared environments. For instance, a project may begin with a narrow scope and require only a single developer’s time.
Project managers and full-stack developers face such choices almost immediately, during the initial development, staging, and deployment phases. On smaller projects, these two goals can be achieved simultaneously but on larger projects – especially given time and budget constraints – it is sometimes necessary to prioritize one over the other. On the other, various programming best practices encourage us to build in an extensible and modular way from the start: Do One Thing and Do It Well.
On the one hand, Agile philosophy encourages us to build and iterate as necessary: Move Fast and Break Things. Intended audience: technical managers, senior developersĪgile developers must constantly strike a balance between building solutions for a known existing case and building solutions that can scale to handle unknown future cases.
0 kommentar(er)
