It seems no matter where you work as a developer, the first day or two is all about setting up the company issued laptop with the necessary tools to do the job. Everyone recognizes how much pain in the ass that is, and how much time is wasted doing it.
As stated in the previous article, DevOps is the answer to the question, "what do I have to change in my process to be able to and want to deploy to production 10 times a day with zero downtime?" The number 10 was not just some random number picked from
The loan origination system my team and I are responsible for have 20 tables marked as static data in Redgate's SQL Source Control. One example of static data is a tile type. The loan origination system has a dashboard made up of multiple tiles. There are six different types of
A core concept of continuous delivery is build once, deploy anywhere. The idea behind it is simple, the code is built once and deployed to all the servers throughout the various environments. For example, if you had a development, testing, staging and production server, you would build once before deploying
Continuous Delivery allows us as developers to respond quickly to feedback to ensure we are meeting the business needs. Being able to respond quickly to changes the business needs without putting underdo strain on our resources will help us deliver value to the company and by extension our customers.
A while ago I was assigned to a project to move all of all the business logic from Oracle packages into C# code. Before I could even start moving the code I had to create a suite of tests covering those business rules in the database. The Oracle packages read
Small releases shouldn't cause major outages. It certainly shouldn't take down a production database server. In the end it was one line of code. That exposed several flaws and brought down the database server.
Wednesday night my team and I deployed a release to production. The release consisted of both