If you’re not yet using a version control system for your website or web service and you’re having issues with slow deployments or rollback, in this video, Marc Firth (Managing Director) at Firney, explains why you need to use version control to enable better engineering processes.
See our Application Modernisation with 12-Factor App series on see the full App Modernisation playlist on YouTube.
Marc Firth (Managing Director at Firney) explains why you should use Version Control and the role it plays increasing scalable, reliable websites, web applications and web services that are efficient to work with.
A transcript of the video above is included below.
Do you need Version Control?
Marc: If you’re having challenges deploying and rolling back code or if you have dependencies that are not tied to a release of your software, it’s likely you have not yet set up a version control system or it might not be structured correctly if you’re managing multiple code bases.
There is also best practice to follow around how to store different code bases. And in this video, I’m going to explain why this is important.
The 12-Factor App
Marc: Hi everyone.
This is the second video in our 12-Factor App series, which is a series of steps to implement to achieve application modernisation.
Application modernisation ensures that your application can be reliable with as little downtime as possible; because no one wants that phone call at 3 a.m. telling them the application has gone down and it helps make your engineering processes smooth and efficient. This is great for us engineers as it means we can move forward with feature development faster and focus on the work that delivers value for your customers.
Introduction to Version Control
Marc: So first off, version control is pretty standard these days but, for anyone who is unfamiliar, let’s discuss what version control is and why we use it.
A 12-factor app is always tracked in a version control system, and this could be a tool such as Git, Mecurial or Subversion.
A copy of the Version Control database is known as a code repository and it’s often shortened to Code Repo or just Repo.
Having a code repo ensures you always have a backup of your software on a remote server somewhere and that you can retrieve it in the case of massive failure; such as when your local machine or server has a complete meltdown. The last thing you want is to have to explain to your manager or team that you’ve lost everything as there were no backups.
You should back up your changes to version control multiple times per day. The strategies for that are another video entirely, but as a first step, you should ensure that everyone on the team is backing up their work to a version control system on a regular basis.
Why is a Version Control System useful?
Marc: A Version Control System lets you merge individual contributions of code from your engineering team members, which are known as “commits”. If there’s a clash where two people are working on the same portion of code at the same time will help you consolidate that into working code so you can have a clean history of combined contributions or commits to the software.
Code Releases are a snapshot-in-time for your evolving codebase
Marc: It lets you create versions or releases of your code base. This is usually a numbered version such as one or two. Although normally these version numbers are split into a numbering format that indicates whether the last change was a major minor or patch [change] such 1.0.1 or 1.0.2.
Having these releases enables everyone to work towards a single version of the software and then everyone’s code and all the third-party dependencies can be tested together. Those dependencies are also versioned. For example, you know that version one of your software works with version six of some dependency, and if there’s ever an issue with a release in your live/production environment, you can quickly roll back to the last known working release as these are all stored in your version control system.
Diagnose the root cause of an issue
Marc: Having a version control system lets you see what changes may have led to an issue. I’m not saying you should go and blame the developer or fire them for committing a bug to the code base. Bugs happen and should be expected, but it helps us quickly get to the root cause of an issue. If you know a piece of functionality was previously working in a prior release, you can see what changed between then and now and add a fix and tests to ensure the bug doesn’t return.
So how does Version Control work in the deployment pipeline?
Marc: A code base is a single repo or any set of repos that share a root commit. That is, they started with the same code and are intended to remain that way, i.e. all the developers working on a single application.
One code base may be copied or pushed to the production environment, many times. These are known as deploys or deployments.
What if I have many codebases in my solution?
Marc: There is one code base for each deployed app. If there are multiple code bases, it’s not an app, it’s a distributed system; and each individual component in the distributed system is an app in itself and they will each individually comply with 12-factor.
So if you have, say, a marketing website and a separate API, those are considered to be two separate apps and each should follow the principles of the 12-factor app individually.
Version Control Best Practice
Marc: Code should never be shared between apps unless it is isolated in the form of a dependency, which should also be versioned. And we’ll talk more about dependencies in a later video, but I gave a quick overview in our first video in this series, which I’ll link to here.
So there is only one code base per app, but there will be many deployments of each app. A deployment is a single running instance of the app. This is usually a deployment which works its way from the developer’s local machine to one or more staging or testing environments before being deployed to production. This is known as the “deployment pipeline”.
Immutable releases
Marc: You should aim for the code base to be consistent and immutable or unchanging as it works its way through that deployment pipeline, particularly after the first staging environment.
You might have differences on your local environments as each developer works on it independently. However, this may not be the case if you have to roll back a deployment. Typically, that will result in a fix which is then deployed through each environment. But they all share the same code base, identifying them as different deployments of the same app
Version Control – Summary
Marc: So if you’re not yet using version control, that’s definitely the first factor towards better software versioning and stability. And it should help you quickly fix any bugs in your software releases for rapid redeployment.
It’s pretty easy to get started with and it’s really widely used. At Firney, it’s definitely the first thing we do when starting or onboarding a project.
I hope you found that useful. Please like this video, if you did; share it with anyone you think benefit; subscribe for more helpful cloud engineering tips and I’ll see you in the next video.
References: