Dev systems shouldn't be backed up!
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
I guess the upside should be that your team have complete control of the machine, right? So you could include backup in your deployments scripts/tool/procedure/whatever, right!? ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
IT is also being squeezed for manpower, so their typical response is only dealing with systems set up to their standards and maintained by themselves. Can't really blame them if their manpower to deal with exceptions has been taken away by a bean-counter not understanding consequences. I would expect the bean-counter got a bonus for saving this manpower in IT. Sure you are going to waste a lot more manpower - but that waste will look like you not being productive, so that's clearly not the bean-counters fault. So in short, he made the right choice seen from the top. If you work for a software development company it is typically a bit easier to get dev systems included (you can argue they are essential to the core business - i.e. server down, production halted) - if software development is just a "side-kick" in the business, then it is going to be hard and you should probably do your own backup. IT might be able to provide a file share you can dump the files on and then they will back up those. Alternatively create scripts setting up the servers - and have that in source control - which is hopefully backed up....
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
5teveH wrote:
Our "ApplicationHost.config" file got wiped a few days back
Why wasn't it under source control?
5teveH wrote:
Dev systems shouldn't be backed up.
Arguable - GIT is there for a reason. You don't back up dev systems because they are not stable, any snapshot in time won't be accurate or valid for long, or it may not be valid at all (i.e. a broken build, broken system due to ongoing changes). GIT is there with branches and commit messages, when you get to a milestone or at least a stable version you just push it in a master / release / whatyoucallit branch with a meaningful commit message and voila, here comes the vackup and the diff history in a single package.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
5teveH wrote:
Our "ApplicationHost.config" file got wiped a few days back
Why wasn't it under source control?
5teveH wrote:
Dev systems shouldn't be backed up.
Arguable - GIT is there for a reason. You don't back up dev systems because they are not stable, any snapshot in time won't be accurate or valid for long, or it may not be valid at all (i.e. a broken build, broken system due to ongoing changes). GIT is there with branches and commit messages, when you get to a milestone or at least a stable version you just push it in a master / release / whatyoucallit branch with a meaningful commit message and voila, here comes the vackup and the diff history in a single package.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
Why wasn't it under source control?
den2k88 wrote:
GIT is there for a reason.
I was thinking the exact same thing. Noobs. :sigh:
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
Nope, not just you. Dev systems need more frequent backups than "ordinary" systems, because it's too easy to lose stuff through a tiny mistake. And dev systems tend to change more than "normal user" data does as well. Not telling you they stopped is ... incompetantcy.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
den2k88 wrote:
Why wasn't it under source control?
den2k88 wrote:
GIT is there for a reason.
I was thinking the exact same thing. Noobs. :sigh:
For our build agents we have an Azure DevOps repository with corresponding pipeline (running on a hosted agent) that can spin up the agent from scratch - including creating the VM in Azure. Besides being great for history and backup, it also discourages people from "just making some undocumented changes" as they know it will be wiped soon. First time I saw this was over 20 years ago now - they had to physically install Windows and Source Safe (yes that old), get one repo our of SS and run a script in it. Then wait half a day. At least there is progress, no Source Safe and my agent spins up from scratch in a couple of hours. Will do until we get all our builds into docker images. We do have one VM deployment target that has not yet been set up this way (used to test on-prem installations) - but looking forward to getting that under control as well.
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
my shop... The entire team is work remote. We have no formal office space. We use Microsoft Teams to communicate and meet. -- we develop locally on our dev laptops, running synchronized local databases using DbUp(see below). -- visual studio 2019, etc. -- We use DevOps and Git. We use DevOps continuous integration with build and release pipelines. -- We use AWS for DEV, QA, UAT, and PROD (applications, sites, SQL Server dbs, etc.). -- Everything that is deployed to an environment (DEV, QA, UAT, PROD) is in source control (Git), including all configuration files (app, web, appsettings.json, etc.). We never backup anything except our databases in DEV, QA and Prod. All code is in source control, obviously. We have 14 developers We have 2 engineers that manage AWS and all build and release pipelines. We have 4+ QA testers. We have 5+ Business Analysists. We have one Release Manager who is also our Scrum master, if you want to call it that. Home - DbUp[^]
-
I guess the upside should be that your team have complete control of the machine, right? So you could include backup in your deployments scripts/tool/procedure/whatever, right!? ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
I guess the upside should be that your team have complete control of the machine, right?
We have a large IT department, broken up into many 'silos'. Developers are just developers and have no say on infrastructure!
Super Lloyd wrote:
So you could include backup in your deployments scripts/tool/procedure/whatever, right!?
Had we known this was the 'policy', yes.
-
5teveH wrote:
Our "ApplicationHost.config" file got wiped a few days back
Why wasn't it under source control?
5teveH wrote:
Dev systems shouldn't be backed up.
Arguable - GIT is there for a reason. You don't back up dev systems because they are not stable, any snapshot in time won't be accurate or valid for long, or it may not be valid at all (i.e. a broken build, broken system due to ongoing changes). GIT is there with branches and commit messages, when you get to a milestone or at least a stable version you just push it in a master / release / whatyoucallit branch with a meaningful commit message and voila, here comes the vackup and the diff history in a single package.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
Why wasn't it under source control?
Because it contained secrets like connection strings and passwords and machine specific information such as file paths that you generally don't want in source control?
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
my shop... The entire team is work remote. We have no formal office space. We use Microsoft Teams to communicate and meet. -- we develop locally on our dev laptops, running synchronized local databases using DbUp(see below). -- visual studio 2019, etc. -- We use DevOps and Git. We use DevOps continuous integration with build and release pipelines. -- We use AWS for DEV, QA, UAT, and PROD (applications, sites, SQL Server dbs, etc.). -- Everything that is deployed to an environment (DEV, QA, UAT, PROD) is in source control (Git), including all configuration files (app, web, appsettings.json, etc.). We never backup anything except our databases in DEV, QA and Prod. All code is in source control, obviously. We have 14 developers We have 2 engineers that manage AWS and all build and release pipelines. We have 4+ QA testers. We have 5+ Business Analysists. We have one Release Manager who is also our Scrum master, if you want to call it that. Home - DbUp[^]
Exactly, source is in source control and can be deployed at any time, including all configuration for that specific environment :thumbsup:
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
5teveH wrote:
Our "ApplicationHost.config" file got wiped a few days back
Why wasn't it under source control?
5teveH wrote:
Dev systems shouldn't be backed up.
Arguable - GIT is there for a reason. You don't back up dev systems because they are not stable, any snapshot in time won't be accurate or valid for long, or it may not be valid at all (i.e. a broken build, broken system due to ongoing changes). GIT is there with branches and commit messages, when you get to a milestone or at least a stable version you just push it in a master / release / whatyoucallit branch with a meaningful commit message and voila, here comes the vackup and the diff history in a single package.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
den2k88 wrote:
Why wasn't it under source control?
Yes, everything we change is under Source Control, but our developers don't make direct changes to ApplicationHost.config. That's done by our deployment tool - which clearly has a bug! But that wasn't my main concern. It just highlighted the 'no back-up policy'. What if we had a complete fail of our Dev system?
-
Nope, not just you. Dev systems need more frequent backups than "ordinary" systems, because it's too easy to lose stuff through a tiny mistake. And dev systems tend to change more than "normal user" data does as well. Not telling you they stopped is ... incompetantcy.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
den2k88 wrote:
Why wasn't it under source control?
Yes, everything we change is under Source Control, but our developers don't make direct changes to ApplicationHost.config. That's done by our deployment tool - which clearly has a bug! But that wasn't my main concern. It just highlighted the 'no back-up policy'. What if we had a complete fail of our Dev system?
5teveH wrote:
What if we had a complete fail of our Dev system?
You broke it, you pay it ;P :-D
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
5teveH wrote:
Our "ApplicationHost.config" file got wiped a few days back
Why wasn't it under source control?
5teveH wrote:
Dev systems shouldn't be backed up.
Arguable - GIT is there for a reason. You don't back up dev systems because they are not stable, any snapshot in time won't be accurate or valid for long, or it may not be valid at all (i.e. a broken build, broken system due to ongoing changes). GIT is there with branches and commit messages, when you get to a milestone or at least a stable version you just push it in a master / release / whatyoucallit branch with a meaningful commit message and voila, here comes the vackup and the diff history in a single package.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
A dev system is much more than just the source files that are copied to it. A source control system is not the same as a backup system.
And you'd trust your company to keep a backup of it? Image, zrchive and up into the backupped file server and you're on.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
One of the problems here is that everything has to be backed up and that leads to long delays in getting databases and such spun up. I used to be able to have local databases as sandboxes, but they won't allow that anymore.
-
... that is, according to one our senior IT infrastructure guys! Our "ApplicationHost.config" file got wiped a few days back - and, (before we found out about inetpub\history), we asked the infrastructure team to restore it from back-up. "It's a dev system. We don't back-up Dev systems.", was the reply. When we challenged this, their team lead responded: "Dev systems shouldn't be backed up." :wtf: Wha? :confused: First of all, it always used to be backed up - so when did that change? Without us knowing? Secondly, the Dev system is the most volatile and most likely to get b*ggered by a developer. Surely, that alone, justifies back-up? I am pretty much gob-smacked by this. :wtf: Is this just me? :~
-
IT is also being squeezed for manpower, so their typical response is only dealing with systems set up to their standards and maintained by themselves. Can't really blame them if their manpower to deal with exceptions has been taken away by a bean-counter not understanding consequences. I would expect the bean-counter got a bonus for saving this manpower in IT. Sure you are going to waste a lot more manpower - but that waste will look like you not being productive, so that's clearly not the bean-counters fault. So in short, he made the right choice seen from the top. If you work for a software development company it is typically a bit easier to get dev systems included (you can argue they are essential to the core business - i.e. server down, production halted) - if software development is just a "side-kick" in the business, then it is going to be hard and you should probably do your own backup. IT might be able to provide a file share you can dump the files on and then they will back up those. Alternatively create scripts setting up the servers - and have that in source control - which is hopefully backed up....
-
And you'd trust your company to keep a backup of it? Image, zrchive and up into the backupped file server and you're on.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
YMMV, but in a lot of organizations it's IT's job to back everything up. Some companies go out of their way to ensure their developers don't waste spend their time doing menial IT tasks. Personally - at home - I don't do any backup from within an OS. I have everything running in VMs, and simply copy disk image files onto other drives, either across my LAN or external drives on USB. Has served me well for over a decade, and even restoring to another host was rather trivial. Not recommended for all scenarios however (eg, I'm not including VM metadata). [Edit] Another random thought: Depending on what you do with them, test systems could definitely disqualify for backing up. I very often find myself putting together test VMs that I would consider to be throwaway systems. But I'd call those QA machines, not dev machines. A dev machine is very often a lot more complex in setting up juuuuust right.
