|
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.
|
|
|
|
|
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?
|
|
|
|
|
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  
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.
|
|
|
|
|
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
|
|
|
|
|
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.
modified 22-Sep-21 12:06pm.
|
|
|
|
|
Exactly.
All my dev is done in VMs which I can snapshot before a major change/update in case it borks. These VMs are replicated automatically between two machines (desktop and a dev laptop) and are also, though only occasionally, physically, backed up to another server just in case! This is all in addition to source control.
On more than one occasion I have had to either copy back one of the clones or at least fire one up to recover something completely destroyed by an OS update etc. (This applies to Linux and MS stuff!)
It is hard to envisage any setup no matter how small or large where backing up dev machines, at least occasionally (when known to be in good working order, say after initial setup and config) is not a good idea.
|
|
|
|
|
Git is limited by the devs who use it. If they keep origin backed up and push their branches pretty regularly, it'll be fine, but even then all that work between pushes is in danger w/o backup of the individual repositories on the dev server.
|
|
|
|
|
den2k88 wrote: 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).
This argument leaves out the time it takes to rebuild a DEV PC, which isn't trivial. My employer has several standard disk images, but none contain all tools a particular developer needs. This also doesn't cover the loss of items backed up to the local git but not the main instance.
|
|
|
|
|
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!
|
|
|
|
|
OriginalGriff wrote: Not telling you they stopped is ... incompetantcy.
Yep! That was the thing that really wound me up! 
|
|
|
|
|
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[^]
modified 22-Sep-21 4:35am.
|
|
|
|
|
Exactly, source is in source control and can be deployed at any time, including all configuration for that specific environment 
|
|
|
|
|
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.
|
|
|
|
|
Only if the devs are full local administrators on their machines, so they can back them up.
|
|
|
|
|
All the important code is in source control and several folders get synced via OneDrive. It would still be a pain to set up my dev environment again, but most things are backed up.
|
|
|
|
|
I've been squeezed for disk space by control freaks and supervising sadists. So, it's not just you. The subtext was: hardware is more valuable than a system programmer's weekends off.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Actually, that makes sense.
The two categories of important data on a dev system are
a) developed product
b) development environment
a) is already backed up in source control. b) has to be easy to set up in the first place (i.e. for onboarding) so you gotta have a single installer or a script which sets everything up. That script, of course, has to be backed up, but the actual dev machine can be set up from scratch on any empty system.
|
|
|
|
|
c) Various servers needed for the CD/CI pipeline (Build agents, deployment targets, ...).
Either you need a backup of these, or (my preference) also script the setup of these and keep that in source control. That said, scripting our LDAP test server turned out to be rather frustrating, so that is just a "step by step" setup guide in our Wiki that could be done in half a minute to an hour.
|
|
|
|
|
A how-to guide is the next best thing and if nothing else, may help someone new to get an overview of the delivery pipeline.
Thanks for reminding me, by the way, I'll have to make sure to back up my CD pipeline as well*!
*When I finally get to set it up anyway. A huge "advantage" of maintaining a legacy pile of outsourced-a-dozen-times bog is finally, after all those years, having the management backup to set it up anew, clean & with all the bells & whistles, including CD.
|
|
|
|
|
Member 9167057 wrote: a) is already backed up in source control.
Yes, but we have over 50 applications that would need to be redeployed. Doable, but a bit of a pain.
Member 9167057 wrote: b) has to be easy to set up in the first place
Sadly not! Not only would this require effort from several teams outside of Development, we would have to put in Change Requests and go through Change Management to get it done. I doubt we would get an empty system ready for redeployment in less than 3 days.
And, as the goalposts have been changed without our knowledge, (i.e. we always used to have back-ups, and now we don't), we haven't exactly prepared for this.
|
|
|
|
|
a) are you talking about applications you produce or you use? If you produce, they shall be in source control and redeployment is as easy as git clone. If about applications you use, that'll be item b).
b) you need outside departments to set up your dev environment? Holy f***ing hell, that's awful! At our place, devs can get (local) admin rights which are enough to set up stuff locally, including local test data (which sits in a Git repo anyway).
|
|
|
|
|
Yikes
I have dealt with the following only:
1) IT owns the server. It is a pain getting changes (change requests, the whole nine yards), but as they own it they also make sure security updates are installed and the system is backed up.
2) DevOps own the server. IT does not care how or why it is changed, because they are not responsible for running it (they might own the infrastructure it runs on and keep that running, there might be some check for antivirus etc, it might be on a separate vnet where IT does not get blamed for problems etc - but in general IT is hands off.
Both kind of works with drawbacks, but I prefer 2. It seems you got the worst part of both of these - let's at least hope somewhere out there a lucky smock who ended up with the good parts of both - though it is probably one or another inexperienced guy who does not even know how lucky he is. Oh well, reality will catch up sooner or later.
|
|
|
|
|
The a**hole who said that should be terminated with extreme prejudice. Urinating and defecating on his grave is left as an exercise by the student.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
