🎙 Develpreneur Podcast Episode

Audio + transcript

Backing Up and Preparing for the Worst

In this episode, we discuss the importance of backing up and preparing for the worst. We cover version control, regular commits, and cloud-based backup solutions.

2020-11-15 •Backup and Disaster Recovery •Podcast

Summary

In this episode, we discuss the importance of backing up and preparing for the worst. We cover version control, regular commits, and cloud-based backup solutions.

Detailed Notes

The episode starts with a discussion of the importance of backing up and preparing for the worst. The host explains that this is especially relevant for developers, who often work on critical projects and need to ensure that their work is safe and accessible. The host then dives into the specifics of version control, explaining why it's crucial for developers to use a cloud-based version control system like GitHub or Bitbucket. The host also discusses the importance of regular commits, emphasizing that developers should commit their changes frequently to ensure that their work is backed up. The host then moves on to discuss backup solutions for non-source code files, such as designs and requirement documents. The host recommends using cloud services like Dropbox or Box, and also mentions Amazon S3 as a reliable backup solution. Finally, the host concludes by emphasizing the importance of backups and preparing for the worst, and encourages listeners to take action and start backing up their work.

Highlights

  • Version control is crucial for backing up source code.
  • Regularly commit changes to version control.
  • Use a cloud-based version control system like GitHub or Bitbucket.
  • Back up non-source code files like designs and requirement documents using cloud services like Dropbox or Box.
  • Use a backup solution like Amazon S3 for storing files.

Key Takeaways

  • Use version control to back up source code.
  • Regularly commit changes to version control.
  • Use a cloud-based version control system like GitHub or Bitbucket.
  • Back up non-source code files using cloud services like Dropbox or Box.
  • Use a backup solution like Amazon S3 for storing files.

Practical Lessons

  • Use a cloud-based version control system like GitHub or Bitbucket.
  • Regularly commit changes to version control.
  • Back up non-source code files using cloud services like Dropbox or Box.
  • Use a backup solution like Amazon S3 for storing files.

Strong Lines

  • Backing up and preparing for the worst is crucial for developers.
  • Version control is a key part of this process.
  • Regularly committing changes to version control can help prevent data loss.

Blog Post Angles

  • The importance of backups for developers.
  • The benefits of using version control for backing up source code.
  • How to use cloud-based backup solutions like Dropbox or Box.
  • The role of Amazon S3 in backup and disaster recovery.
  • Practical tips for implementing version control and backup solutions.

Keywords

  • Backup and disaster recovery
  • Version control
  • Cloud-based backup solutions
  • Amazon S3
  • Dropbox
  • Bitbucket
  • GitHub
Transcript Text
This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our series of one-offs. In this episode, we're going to talk about backing things up. We're going to talk about preparing for the worst. This is a particularly important piece of the thing, a recommendation, I guess, when you're doing side hustle stuff, when you're doing things that are not your day job, your main work. Because typically these days, depending on where you're working, but in most places, you're going to be in a situation where your employer for your day-to-day work is pretty well set up as far as backing things up and security and your ability, especially now in the last few years, your ability to access critical things, source code, build scripts, things like that, wherever you are. Now, yes, you may have to log in via VPN or something like that, but there is usually going to be some sort of remote access configured. There's going to be backups. There's going to be all kinds of stuff. A lot of things are out in the cloud. So you're safe. Regardless of what happens, you should be able to access what you need to get the job done. Now, for your personal stuff, you may not do that. You may have a development laptop that you use and you may carry it with you wherever you go, but if that laptop dies, if you don't have backups, then you're lost. Now, there's a lot of things that we go through that should take care of that, but I think it's a good time to just because you want to make sure you have everything in place before you need it, I think it's a good time to talk about some of the things that we should do to ensure that we don't lose our work, that we practice what we preach, that we are safe and secure. The first one, because we're talking usually development, whether it's scripts or source code, is to have version control. You want to be able to not only access something that you did, but not just current, but something you did in the past as well, just in case you need to roll back. And these days, it is so easy to use like a GitHub or Bitbucket or some of those kinds of Git-related version control systems, and they've all got really good clients floating around depending on what operating system you pretty much live in. There's almost no excuse to not use version control, your software. It may seem like overkill if you're the only one that ever commits code, but I think it's professionally, it is very helpful to get into the habit of regularly committing changes. Even better than that, it's very professionally useful to have a habit of branching, working on a branch, committing regularly, and then committing or merging up that branch once the work is complete. You may be like me, and there's a lot of projects where I'm the only developer, so as long as I commit regularly and do some tags, I'm probably going to be fine. I don't really need to branch, but it is useful to get into that sort of branch habit. I personally haven't gotten bitten by it, but have had the opportunity to get bitten by the fact that I usually have at least, a lot of times, at least two different places that I'm writing code. I have a desktop and a laptop that, depending on where I'm at or what I'm doing, I may code on either one of those at any given time. I actually use, I have Dropbox, which I use to sync files, and we'll talk about that a little later, but I also use Git. I've got a couple different Git software as a service solutions out there. I use both GitHub and Bitbucket, and I will commit to those. The nice thing is if I commit on, let's say I'm doing a laptop and I do some work, I get done, I commit, then the next time I'm on the desktop, I will see that, hey, I had a commit on the laptop, so I need to synchronize my code in. And sometimes I'll jump into coding too quick, and I won't see that, hey, I had changes on this other one, on this other device, so then I need to merge them all in. That kind of stuff is going to be crucial, particularly if you're bouncing around where you do your code. You want to make sure that you have all of your changes and you don't end up in a situation where you, for example, you're coding on a laptop and then something happens to it, and then you're not able to get access to it. So now you're not able to get access to code, and either you have to stop progress until you can get access to that code again, or end up a situation where you're like, did I code that? Did I not code it? And so that also brings up the commit regularly. Ideally, you should, and this is why it's helpful to branch, because then what you can do is you can branch, have a local branch, very easy to do with Git, have a local branch commit regularly, several times a day. If you're in a coding session, maybe in that coding session you don't need to commit, but when you finish it, commit. If you do something like a Pomodoro technique, then go ahead and commit at the end of every Pomodoro cycle. Particularly if you're on a branch that is not something where you're in a situation where you need to have working software that's committed, you can do a commit and just say, hey, I'm doing this, this is a work in progress. It's not complete. And if you're on a branch, that's fine, because you don't really need to worry about it being complete or working until you merge that branch in. So when you take advantage of that, that allows you to code from different places. It is very useful, especially side hustle, if you've got a team, if you've got one or two other people working with you on that side hustle. I've done this many, many times where I have worked with one or two other developers. We're all sort of working at random times. We're all getting into various, maybe in the same code. And so we do some commits. We branch stuff off, particularly feature related branches. So I may be working on feature X, somebody else is working on feature Y, and then we, at some point, get together and do a merge and build and get everything going forward from there. So version control is number one. If you've got that, particularly if it's on a cloud server, then that's probably your most critical thing that you're doing is backing up that source code that you're creating. Now that brings us to the next thing we need to worry about. Source code is not our only valuable thing that we're creating. We have designs, we have requirement documents, we have emails. There's a lot of stuff that we have that we do need to keep track of. Most of those documents, the easiest way is to use something like a Dropbox or Box or Microsoft's solution. I forget what it's called off the top of my head, but there's a lot of different options out there. stuff like that. Now, which one you use will probably, or at least should depend a little bit on your security concerns, because some of those, be careful, particularly the free options that are out there. Usually, part of the free option is that they essentially have, they say they can look through your stuff, that there's no guarantee of security or anything like that. In which case, if you're doing something like that, you may just make sure that you encrypt anything you store on one of those cloud services. You don't need to do the sync, although I love being able to sync stuff via Dropbox from machine to machine to machine, because I bounce around. Maybe you use something like that and you just have some sort of a backup where you press and encrypt your files and then just store them out there for regular backup purposes, sort of like an old school offsite backup. For now, you don't have to send it off in tape. You can just throw it out in the cloud and boom, you're ready to go. You may also do something like Amazon's S3 or something like that. Use some file storage out there. If Azure or one of those other cloud providers, you just throw your files out there. Make sure you do it on a regular basis. I would say daily is good, but probably at least weekly. Then you can rotate your backups and all that kind of stuff as well. Ideally, because it's an option, I think it's pretty good to have something where you have something that regularly syncs stuff to the cloud, preferably in a secure manner, so that regardless of what happens. If you're sitting in the middle of the day and power outage or something like that, that your files have been pushed out to the cloud. A simple example would be, let's say you're working on a laptop and spill your coffee all over your laptop and things fried. Well, you're going to lose whatever's on that laptop, but if you've been regularly backing stuff up, then you can possibly jump to another machine almost immediately and access all files and not miss a beat. Or, worst case, you get a new laptop or repair the one you have and then restore from the cloud. At least you haven't lost work. These things may seem, I don't know, trivial is probably not that, but unlikely. Let's just face it, if you're working in technology for all the time, as we are, 40 hours a week plus, there's going to be situations where things are going to happen. Maybe a laptop gets dropped or a desktop gets kicked or you're vacuuming the floor and a desktop's on the floor and ends up getting too close to the vacuum and the electromagnetic field erases the drive. Something that I know somebody else has run into before. You may have all kinds of just odd, you can have a lightning strike. There's just all kinds of stuff that can happen that can fry a machine. Now the newer stuff is better. You have just less moving parts. You have SSD drives and things like that. They're more stable. They're less likely to have issues, but that doesn't mean it's 0%. You really only need this to happen once for you to realize the value in it. A good example, years ago I had a laptop. Got a new laptop. It ended up being essentially a lemon. It died after about two weeks. I sent it in for repair, came back, got everything reinstalled, died again, got everything reinstalled. This was after a couple of days. Got everything reinstalled again after the third time I went. Finally, they wouldn't replace it, so by the fourth time I sent it, I just had to go buy another laptop. I still use that one. Of course, the fourth time was a charm. Never had issues with it again. But I also never used it as a primary laptop again. It literally cost me too much to do the reinstall. This is back when you didn't have networks and cloud providers and stuff like that. This was everything had to be on. It was all like a CD or DVD and all that kind of stuff that made it a real pain to rebuild my environment. It was also Windows machine, which meant there was a whole lot of installs that I had to do to get to where I wanted to be versus a Linux or Unix base where I could just basically plop files in and boom, I'm off and running. I don't have to worry about this convoluted install process for the most part. Of course, there's also the whole downloading stuff. If you've got stuff that you're working with that you've downloaded, it makes sense to back that up somewhere. I have seen this both from the need for a specific version. For example, I use Eclipse all the time. Maybe I get comfortable and have everything configured for a certain version of Eclipse and a certain version of Java behind it and things like that. Well, if I lose everything, I could go get the latest version, but that may not be what I want. That may cost me time because I may have to upgrade some other stuff. Instead of having to figure out where was that older version, I just have it sitting out on a drive somewhere. Like I said, a lot of companies do this. It's not a bad habit to get in personally. Whatever your current, essentially what your current working software is, have a place to store that so that you can always go back to it and reinstall it if you need to. You may be able to just do a full system backup and then you're fine, but it usually doesn't hurt to have that software anyways. That's particularly if you've, even if you're going to go to another machine. Let's say you're working on a desktop. You save up, you get a laptop, you're ready to go with that. Well, you need to install the right software into it unless you can do some sort of a ghost image of one to another. Save yourself some headaches and just make sure you save those. As you pull that stuff down, save it off somewhere so you can go back and say, what was that version? Oh yeah, this is the version I needed. I'm going to go grab that and move forward with it. The more you do that, the more you document those kinds of things, the easier it is overall to get things done and get it done quickly and get back up to speed when something goes wrong. And of course, things will go wrong. Now, the last piece I want to make sure that we think about when we're doing our backups and planning for things to go wrong is our notes. Now, some of us use pencil and paper, pen and paper, something like that. Some people, I know a lot of people have notebooks, physical notebooks that they use. Some use an edit program and just keep text files around. They may use something like Evernote or some solution like that. Whichever solution you use, make sure that you have that configured so you have access to those notes when you need it. Now, something like an Evernote, I know a lot of people like that because they can do it on their phone and tablets and desktop, laptop, all that kind of good stuff. They can use it everywhere. But you also have to pay for it. There's other things that are just as easy and maybe just as cheap to use a wiki site or to just store some text files. But if you're just doing it in text file notes, make sure those are like we've talked about these other documents. They're somewhere where they're going to get stored off, backed up, whatever it is so that you can get access to them when something goes wrong. These three main areas are probably going to cover you. But I think that's where we get to really with the challenge this week is think through. This is probably worth taking a little bit more than just a couple of minutes. So maybe just do this in a couple of different settings to put it in the back of your mind maybe over the next week or probably over the next month. Think about what are the things that you use on a regular basis. Regular is daily, weekly, monthly. Because there are going to be some things potentially that you only touch once a month, but you really need access to those. For example, maybe you have a quicken or something like that that you use for your personal accounting or your business accounting. And you only touch it once a month or maybe even once a quarter. But you really need to make sure that you have that backed up so that if something goes wrong you can go see what were the transactions that you posted. You may have some sort of reporting that you do. Invoicing, there may be an invoice program that you only touch once a month, once a quarter. But you want to make sure that you have access to those past invoices plus the ability to create them. Obviously there's the daily stuff. Other IDE you use, source code that you have access to, documents you read on a regular basis. Potentially even things like passwords and IDs, depending on how you store those. There may be certain web links. Maybe there's certain websites or logins that you do on a regular basis that you have to be able to reproduce those. That may include some sort of security connections. PPConfiguration, public keys, things like that, private keys. Keep that in the back of your mind. If you haven't already done this, keep this in the back of your mind and build out essentially a list of what do I need if where I work or the places that I work, if they were suddenly wiped off the map, what would I do to be able to get back to being productive again? It's good to think about this because you never know. We've seen this as you had people that left work one day, thought they were going to come back the next day and didn't because of the COVID restrictions, because of lockdowns. There are people that have stuff that's sitting, probably there's some places where people have stuff that's been sitting on an office desk for months and hasn't been touched because nobody's gone back to that. You have situations like that. You want to make sure that you are prepared as much as you can be to be able to adjust to whatever changes come out there. It's one of those things that's not going to hit you every day or every week. It may only happen once in a blue moon, but when it happens, if you're prepared, you'll be happy that you did so. Now, after that somewhat downer of an episode or whatever, don't worry, this stuff does not happen that often. It's just good for us to, it never hurts to think ahead a little bit and be ready. Prepare for the worst, assume the worst, prepare for the worst, and hopefully the best happens. I wish you that as we go out there. Go out and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Developer Noir podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoir.com. Just a step forward a day is still progress, so let's keep moving forward together. One more thing before you go, the Developer Noir podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, it'd be great if you go out to developernoir.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.