3 Key Version Control Mistakes (HUGE STEP BACKWARDS)

Version

control

is essential in software development and git is the king of

version

control

in a recent publication in the online magazine infow World. Ask yourself: what comes next? What's beyond git? I think this is the wrong question or at least less interesting and I think the right question is scarier and goes much deeper into what we really mean when we talk about

version

control, so let's take a look. Hi, I'm Dave Farley from Continuous Delivery and welcome to my channel if you haven't been here before. Please subscribe and if you enjoy today's content, like it too.

Version control is a key idea in software development, it is essential to control the variables that allow us to build on more solid foundations, but we often forget how important it is and often do not take it. Advantage of the power that Version Control gives us is fundamentally about being definitive and precise about the versions of software that we are using in a given context, if you cannot reproduce your software exactly as it was at some point in its history, then no No I'm really taking advantage of version control Version control allows me to define what I mean when I want the answer to questions like whether all the pieces of my application work together without version control.

I can't say what all the pieces that allow my software to work or stop working really are despite this core value. I think it is a tool whose importance we often underestimate in our cost. Version control is the cornerstone of continuous integration and continuous delivery and it doesn't really make much sense without a good foundation. Version control and what version control brings to the party are two things: a clear definition of what comprises a particular version of our Cod Cod, the set of things that make our system a coherent whole, but also, Crucially, the ability to go back to any previous set of those things accurately so that we can recreate them together in a functional form.

This reproducibility is the basis of continuous integration and continuous delivery. Our goal is to be able to recreate our system with sufficient precision in any time so that we get the same results every time In this episode I want to describe the central role of Version Control but also highlight three vitally important ways in which we are currently ignoring its value as a tool and why that is much more important than which comes after git, which if we are not careful will represent a

huge

step

backwards

, however, the help driven by the future of software development may prove to be, let me pause and thank our sponsors.

We are extremely fortunate to have the sponsorship of equal experts in transic and more. of these companies offer us products and services that are well aligned with the topics we discuss on this channel each week, so if you are looking for excellence in continuous delivery and software engineering, click the links in the description below and check them out. Depending on how you think about software development, this idea of ​​reproducibility as a fundamental aspect may seem wildly obvious or perhaps quite strange, of course. Version control means being able to recreate versions of our system, but that is only true when we choose to take advantage of the benefits it offers us.

If I have two applications, two services, two components, two functions, two or more of anything, in fact, what? How do I know if they work well together? There are two parts to answering this question: Are you meant to work together? Version control is a tool that we can use to explicitly define the parts that should work together and that helps a lot to solve this second problem and also confirms that things really work together if we put service A and service B in the same repository. we are saying that the repository defines a sensible scope of evaluation that we are willing to defend in some way.

The things outside the repository are not as important to our system as the things inside it have implications for how we work with it. It means that we can assume that everything in the same version is meant to work together. The Version Control scope defines this relationship. Only once we have that definition can we sensibly verify that the pieces we expect to work together actually work even if this testing of the pieces working together only takes the form of us releasing the software to production and crossing our fingers and hoping that the things aren't so bad, it's still the same: we're still evaluating a specific known defined version of the code when we do that.

Without that, we are simply betting on chance and guesswork. If version five of service A plus version 17 of service B is represented as version two of our application and version two has 34 bugs, we can only create exactly that complete software combination with are 34 bugs and start fixing them if we have a controlled version of that relationship somewhere, if we fix 15 of the bugs in version 2.1 and 16 in version 2.2, we can now be sure that version 2.2, as long as it was built on top of 2.1, will work. Now we only have three of the original bunk beds left. Version control gives us predictability and determinism.

It allows us to make incremental progress that would not be possible without it and, even more importantly, if we fix 31 bugs in 2.2 but then introduce a disastrous bug into our system. In the next version 2.3 we can roll back to the more stable 2.2 and try again. This is even more important for our ability to achieve incremental progress which fundamentally depends on our ability to build on what we had before to accurately restore a known set of software, etc. reliably and repeatably recreate specific versions of our code and systems. This ability to roll back to stable, safe versions when we make a mistake is vital and fundamental to our ability to build complex systems.

This value is so important, so fundamental to effective ways of working. I think all of this should make us think very, very carefully about how best to use this powerful tool, but it doesn't seem to me that we often dismiss this Advantage too easily and without much consideration of its value. What we're throwing away when we do this is true in a variety of circumstances, for example how are the boundaries of your code repositories defined? A large proportion of the teams I know seem to do this somewhat arbitrarily, one repository per service or per team perhaps, where are the dependencies and relationships between the service or teams defined?

Often nowhere, so systems are no longer reproducible or repeatable without a lot of additional, often very complicated, work that could have been handled by simply using Version Control to establish and recreate. the relationships that really matter to you This brings us back to the old topic of this channel, the problem of microservices, which I think boils down to how we choose to exert control over the versions of our software, if A depends on B, we can code the exact version. The versions of A and B that we know work together, which is most easily done using the tools we have at our disposal that allow us to do that version control or we can design A and B so that they don't care what versions they are. the other is because they will always work together.

The crazy option, which is pretty much what everyone prefers, is to worry a lot about versions of A and B, which means we need to test the exact versions we put into production together before putting them into production. production but not to Version Control and Define what those versions are. This is the first of my three irrational failures to apply Version Control properly. We should use Version Control to control which versions work together. My last example is probably one of the biggest challenges we face in the future of software development, but we'll talk about that later, before we get to that, it's a failure that I think has severely limited the adoption of tools that should make it easier for us. programming to everyone.

The lack of use of Version Control by almost all users. programming system I've ever seen But particularly in low-code or no-code systems, I describe this in more detail in this video. Low-code and no-code systems are still programming and programming is still a bit complicated even if we don't do it. To a large extent, writing the value of Version Control allows us to recover from errors and does not disappear with programming systems with little or no code. Perhaps the most familiar examples of these types of failures are found in spreadsheets. Spreadsheets are probably one of the most common forms.

Of the most widely used user programming systems, certainly the most common spreadsheets like Excel are also sophisticated programming platforms these days, but they often seem more like toys compared to modern programming practice in using ideas like the version control and testing the result of this is very Commonly serious business errors are the result of errors in spreadsheets. Austerity The UK Conservative Party's 2010 policy was based on a spreadsheet error: it calculated that a country's economy would contract when its debt exceeded 90% of GDP, when in fact it continues to grow. As a result of this spreadsheet error or at least the austerity policy that resulted from it, it is estimated that over 120,000 deaths in the UK population clearly this type of failure is more than just version control, but that version control, as we have already discussed, allows us to safely move away from errors and Version Control aligned with the policy of moving forward in small

step

s gives us a form of detailed control that would otherwise be completely missing and , combined with testing every small change, allows us to exercise much more control in designing the software we create rather than just crossing our fingers and hoping our calculations were right the first time without verifying them properly - last on my list of three is possibly an even bigger problem for the future, although everyone I talk to these days is obsessed with the idea of ​​AI and its impact on coding.

Not surprisingly, AI offers easy and cheap access to almost instantaneous results in software development. I know there's a lot more to it than that, but that's the selling point for many. many companies in the software development industry, but how does AI write code? Mostly it does it the way most naive beginners assume that we should all write code, we should think hard and then the solution comes to our minds fully formed as if it were a gift of inspiration from the coding gods, but that is now real. Software systems are built. Software is always built incrementally in a series of small steps with reflection after each small step and frequent explorations, missteps, and changes of direction along the way as we learn more and more about it. the nature of the problem we are solving and our particular solution, the effectiveness of our design choices, etc., we change our minds and alter course based on what happened before, so being able to restart when we make a misstep is critical For the practice of software development, you can think of this in terms of our cognitive limits, no matter how smart we are, there is always a finite limit to our cognitive abilities, the cognitive capacity of our minds, if you will, and there are There are very few ways we can extend the scope of these cognitive limits to build more complex systems that surpass those limits.

We could think a lot. We could study really new things and learn more, but that's it. We can work to increase our own capacity, but this It's very serious. Limited in how far we can go. For us, the much more scalable approach is to break the problem into many smaller parts, each of which fits our cognitive capacity, so now our ability to solve problems is effectively unlimited, at least within the limits of what is physically possible. This second approach is how humans actually do it. To solve problems, we build systems and solve problems that are far beyond our mind's ability to contain all the details.

This second unlimited focus is not limited by the capacity of our mind. This remains true even for AI, where it is easier to imagine. that can improve their own mental abilities far beyond ours, being able to solve problems incrementally in smaller steps is always still the most scalable solution, even if their mental capacity is a thousand times greater than mine, regardless of the size of the measuring rod do not alter Thisis the truth of this statement, but currently this is not how AI writes code at all. If you specify what you want from an AI system, it generates the code from scratch.

If you ask it to do it again, it generates it again from scratch. things differently every time, so we have lost reproducibility and with it the ability to fix bugs and grow complex systems incrementally, even if we keep all entries in version control, we have lost version control over our own solutions. This seems like a pretty serious limitation. of what AI code generation can actually do to me until AI can refine, refactor and add to the design of pieces of software, it will be limited by its own mental capacity to understand only when it is able to work incrementally and build on solid foundations that you already have. established in previous steps, will he be as capable as we as humans in solving problems, even if his mental capacity is greater than ours?

Working incrementally in small steps is the most powerful tool here and we achieve this by better controlling variables through Version Control. Thank you so much for watching and if you're a Patreon member, thank you so much for your support. If you are not yet a Patreon member, please consider supporting the channel by checking out the links in the description below. There are good offers. of the time available for patreon members thanks again