Get ready for a surprisingly easy strategy for ensuring your code releases are in sync with external libraries, scripts and packages – dependency management.
What is a dependency manager?
This is the third video in our 12-factor Application Modernisation series in which Marc Firth (Managing Director at Firney) explains software engineering best practices around working with third-party packages using dependency management.
See our Application Modernisation with 12-Factor App series and the full App Modernisation playlist on YouTube.
A transcript of the video above is included below.
Managing third-party libraries, scripts, and software can be a challenge
Marc: So one of the challenges with deployments and rolling back a deployment is it can be challenging to keep track of all the dependencies that your software uses and the versions of those dependencies unless you’re automating that process.
There is a better way through automation. So let’s dig into that.
The 12-factor app
Marc: Hi everyone.
So this is the third video in our application modernisation series where we’re talking about how to make scalable, reliable and efficient applications.
These are techniques we’ve used on sites that we’ve managed in the past that have had to scale to millions of visitors every day. The solutions that we’ve built have become scalable, reliable and efficient by implementing these techniques. So, we’re sharing this with you in the hope that you can benefit from those techniques also.
Explicitly declare and isolate dependencies.
Now, the second item in our 12-factor series is that “you should explicitly declare and isolate dependencies”.
One of the key things you want to aim for is to create immutable or unchanging releases. We’ll come back to the word “immutable” many times over the course of the 12 factors. What you want [to do] is to create a snapshot of your application that you can deploy to any environment.
You have both the snapshot of your code and all the third-party libraries, scripts, plug-ins, and everything that you’re using in your code to build your application.
Those third-party packages all have their own versions, and they need to be upgraded and downgraded. If you’re handling all of that manually, it’s challenging to keep in sync with what version of your software works with the corresponding versions of the dependencies.
For example, you might use a plug-in such as Imagemagick to optimize your images (compress your images).
A 12-factor app never relies on the implicit existence of system-wide packages.
What you need to do is take all of those third-party dependencies and put them into a dependency manager. This is usually in the form of a manifest file, and a corresponding piece of software such as composer for PHP, NPM for Node.js and RubyGems Ruby, and other languages will have their own dependency managers.
When you create a release (if you haven’t seen our video on version control, I’ll link to it here), the dependency manager is run as the image of your software is built. That creates a snapshot of your code with all of the dependencies that correspond to the version of your software. That, in turn, becomes your release in your continuous deployment pipeline.
What should you vendorise?
The key things to vendorise are anything that’s called with the Shell (Command Line) or any third-party APIs that might be using libraries in your code to work with those APIs.
What is the benefit of using a dependency manager?
The benefit of using a dependency manager is that you can quickly deploy and roll back versions of your software in any environment.
- If you need to onboard a new engineer, you can quickly set up their local environment, making sure it’s got all the corresponding packages for the latest version of the software that’s being worked on.
- If you need to set up a new release on another environment for testing, you can quickly do so. You can ensure that it matches up to any other environments you need it to easily.
So, it’s quick to create a release with all of the correct dependencies for that environment. There’s no need to manually install every dependency that your application needs to work with. The dependency manager will handle that for you.
Include a README.md
The final thing we include in this step is a README in your application’s code in the version control so that you can have engineers onboard themselves onto the project. This lets them run through every step needed to get their local environment up and running.
You should also include:
- Any “gotchas”
- Frequently asked questions
- Any details that you might need to include on any of those dependencies
Put all of that in the README. So it’s all in one place and easy to find.
Summary
By implementing the first two items in the 12-factor methodology, you already see more stable releases and environments, and it’s quicker to deploy and roll back your code.
In the next video, we’ll discuss config and how to manage those variables as your code moves between environments.
I hope that was useful. Don’t forget to Like, Subscribe and Share. Do all the things, and I’ll see you in the next video.