![]() This causes major outages (looking at you Netflix), security breaches (looking at you Equifax) or a ton of time wasted trying to figure out why your entire tech stack went down (looking at you every single software developer ever, including myself). This has resulted in a wide variety of solutions across the entire software industry. You don’t want to accidentally promote your test Stripe keys to your production environment or forget about them all together.Īlthough configurations are required literally at every single step of the SDLC, there is no stage defined for it and thus it has, unfortunately, been largely ignored. When you release your code to production you need to have the right API keys in the right places. When you are building with Jenkins you want to run against a mocked or test environment (don’t want to be running those e2e tests against your production servers). Even if you want to point your local environment to QA for some external services, you are still changing the context of how your code runs. When you’re developing you are using your local environment and have one set of configurations. With all of these tools and processes in place we are still missing a proper way to manage our configurations. During every step of the way your API keys, configurations and the context of how you run your code changes. The one big missing piece that glues all these pieces together is the management of your configurations. BUT, there is still a missing link in this evolution. Communication has gone from never ending email threads (well we still have those unfortunately) to using Slack.Īll in all, the software industry has been focused on how to deliver more value, at a faster pace while not sacrificing quality. We went from rigorous spreadsheets and gantt charts, to an agile way of delivering products, from 100 page long manifests, to tools like Jira and Asana. The improvements in project planning and communication have also helped everyone involved to deliver better products. It’s not just the coding and delivering software that have come a long way. Whether you are scaling up your pods on Kubernetes, making sure your application isn’t logging errors in ELK or just keeping an eye on your performance metrics on NewRelic you need to ensure that your code is up, running and doing what it’s supposed to. ![]() The point is your code is live, users are using it and loving it.Īfter you release and deploy you have to make sure that your applications are healthy, withstanding the load, recovering when they are down… Whether you use Kubernetes or Rancher for your orchestration and container management and AWS or GCP for your infrastructure for this article it doesn’t matter. While before we used to literally have “ integration hell”, we are now at a pretty good place when it comes to integrating different components. Release & DeployĪfter all your hard work, your tests all pass, your test coverage is at 100% (am I right □) the fun part starts. All these tests can and should be ran by your build process that is defined previously. You have your unit tests, integration tests, UI tests… You can use tools like Mockito for Java Spring projects mocha, chai for javascript/typescript projects selenium for UI testing and while how you use these tools varies, the motivation as to why we use these tools stays the same. In order to build the code while deploying we use tools like Jenkins, Circle CI, Travis… Testĭepending on your stack and testing goals your tools may vary but it boils down to the same thing. To ensure developers can build and run the code locally we have docker. This part is also locked down with some very well defined processes. After you code you go to the next step which is building. This allows multiple developers to work on a single project in unison. You code collaboratively using tools like Github, Bitbucket, Gitlab (or for those of you who hate yourselves, SVN). It boils down to a software development life cycle (SDLC) and product/project planning and can be broken down into the following sections. ![]() The way we deliver code in modern day software development is more or less the same across most places. For the sake of brevity, and to not give any old school developers terrible flashback of code on punch cards, the timeline I am discussing will be focused on the last 11 years (when Github went live) and the one GIANT step we missed when it comes to managing and deploying your software. The way we develop, test and deploy software has been advancing in leaps and bounds over the last 10 years or so.
0 Comments
Leave a Reply. |