Hey, everyone in this video, we're going to be discussing Version Control. For the most part, we're going to be looking at it as a software tool to use on application development projects. But I will touch on how to apply some of the concepts to a service based design. So what is version control? It's generally a software tool, which you use to track changes to documents, software programs and data, and revisions can be compared, restored and possibly merged, and it can be used either individually or in a team. Now, one of the reasons why you might want to also use version control is if you're looking at rebranding and repackaging an application that you've got, or if you apply it to a hardware physical product, you may see okay, all the background work and mechanics are done. But if we repackage the outside, we can appeal to a new market. And I'd like you all to keep that in mind when you're looking at launching your company. What is the basic infrastructure and architecture of your product, whether it's software, service or a piece of hardware where you can change the exterior design or a few of the functions in order to branch off, create a new product line and move on to another market. Like, just because you may appeal to one, it doesn't mean you can't tweak it a little bit and then use the R and D that you've already invested in to hit new markets. So DevOps is a growing approach to software and application development, especially in the public sector. So looking at this here, where we go source control or version control in DevOps, code, build, test, release, deploy, operate, monitor, plan and it goes in this sort of an infinity loop. DevOps can also include when you look at full stack software development. Now, let's just say you've got a software program or platform that you'd like to build, and you're trying to integrate all these different components. The use of version control tools will help you to see where there may be inefficiencies in the integration, where some of the different versions of a feature maybe using up a bit too much memory or way too, might not be as robust enough as you need for its use. Now you might think, okay, well, this feature with this sort of an architecture is great, but not necessarily for this. But let's just put it aside for now until we can rebrand and package this other thing and then reintegrate it and move it on because it's really good to be able to keep reselling things so a different way. An example from a standpoint as well, when you look at branding and a physical product. When Coca Cola wanted to be able to hit new markets and be able to sell to men, there was sort of like a bit of a sort of a reputation that Diet Coke was for women. Coke Zero came out, and that's a little bit more macho, I guess. But it was to appeal to a new market. So reasons to use version control, making mistakes and you want to undo them. This is very, very common and also lost code. This can happen a lot when you're dealing with teams and you've got different developers coming in and out. So if you're looking at, say in the public sector with software development on for different government agencies, a lot of them are dealing with teams where the government contract is like an IDIQ. So an IDIQ is like indefinite demand, indefinite quantity, I believe. But you can bring in developers, and they can leave and they can move around, but generally the hours of what the contractor and the subcontractor bill for. So when you've got people coming in and out of teams who maybe a little bit nomadic as software developers, it's a good idea to be able to ensure full accountability and responsibility so that if a developer does move on, you can take a look at that. You can see what was going on, not just kind of like, wow, man, what happened here, and allowing for documentation can give you the thought process of what was in the mind of the person while they were writing it and reasons why they took a certain approach. And the same sort of thing when you've got a program manager or a product manager, portfolio manager who's controlling different things, keeping a log and documentation will help the people who come in or replace or build the team will help keep everyone on the same page. And when we look at robust of design and being able to keep track of our production costs, staying within scope and scale is critical. Losing your code, definitely not good for achieving that. So, see differences between two sets of codes. If you're kind of torn on which approach to take for a specific tool within an application, then you're able to run your design of experiments and see where you're hitting the specifications that you need. So a lot of this with the use of version control, is some of the, it's the same sort of approaches we apply to using a design of experience where we shift the parameters and come in and look at what the probability of a certain outcome will be. Because, remember, with robust design, we're trying to work with non ideal conditions and get a software feature or a function or a physical product or a service to achieve the same desired results when there are some noise factors involved. So types of version control tools. Subversion, git, clearcase, CVS, fossil, mercurial GNU Bazaar. With subversion and git, this is a tool that a lot of my developers use, they almost always use subversion or git. You'll generally use either one or the other. Some people have preferences, but for the most part, all of the engineers who work for me who are software developers they use subversion and git. How to choose version control software. So licenses, when you may be joining a project where there are certain technologies that the contractor won the bid by pitching to the customer, or the customer may be married to a certain tool like, well, we've got an arrangement using this technology. This is what we use across the board. And switching between different platforms, that also starts to cut into your productivity and being able to fully keep track of things. So when you pick one, it's best to kind of stick with it. So, platforms, Windows, Linux, Solaris. Most of my engineers develop with both Windows and Linux, and also a little bit of Solaris. Features, centralist control versus distributed control, ease of use, and there are various options. So when you look at version control software, there are some open source tools. So when we go back and take a look at open source sorts of technologies that you can use for developing your applications or software, this can be a good option if you're trying to keep the production costs low. However, remember we go back and we make sure that we do full comparison reports. We look at reviews and we see where and how some of these tools may work for us or may not. And with version control later on, we'll be tying in testing, automated testing and manual testing. So in summary, generally you can use a tool for teams or individuals. For those of you who are developers and are looking at building software, you may initially just be thinking, well, I'm going to build up myself. However, it's best to lay the foundation now and the original infrastructure and these habits for being able to bring on developers because I have seen this before with engineers where they might have a tool that they build and like okay, well, I'm the only one building it. Why do I need to have any documentation? Why do I need to let people know what I was thinking? And then once the tool becomes popular and like, well, I guess I'm going to need to get some more developers up in here. And then the new developers come in like what's going on, man, this is like all cobbled together and. As the owner of a company, I can tell you it's a little bit distracting from me going after the sort of work that I'd like to be able to do [LAUGH]. But however, so when you're using version control software, I'd suggest for those of you who are developers or if you're outsourcing it, get them to use version control software from the very beginning and start to keep different, back up the data and make sure that you keep it so that you can stay on track with different things and compare the source. Because once you start running your testing, both automated and manual, it can be really difficult to find where the glitches are, especially when you've got a highly complex system, that can be tricky, and that also comes into play when you're looking at use a proprietary software, intellectual property, patents and basically you want to have full documentation. Thanks
