A run through of dev ops for beginners covering some basics to get your started:
- Git & Version Control
- Dependence Management
- Automation
- Deployments
Video
Transcription
SAM: Hi, welcome to track C.
I won’t do much announcements now seeing as we had the opening remarks. The luggage room is still open if you have luggage in here now, that is open before 10:00 o’clock.
You might want to get rid of that first.
If you are tweeting about this session, use the hashtag WCLDN I think that is it.
First up, Stewart Ritchie, the lead developer of Powered by Coffee.
Part of Stewart’s job setting up and managing the DevOps for his company, welcome Stewart. (APPLAUSE).
STEWART RITCHIE: Thank you very much.
So this is dead cheesy, before we get started, can we get a big round of applause for all the volunteers who put WordCamp together? Everyone any other T. shirt has been here from 6 this morning, be kind to them, they are here to help.
So as Sam said, I am going turn on my slides, how do I get this back on?
There we go.
This talk is on DevOps for beginners, I run tiny organisation called Powered by Coffee. We are two people and some contractors, you don’t need to be massive for any of this to apply to you, we use the tools all day, everyday this is how we work.
Furthermore, this is not a tutorial. If you are a dev looking for code samples and examples of how to do this, you are going to be disappointed. This is really an introduction, we will look at the high level concepts of DevOps this is for junior, and managers what want to know what they are talking about with some of these things and for business owners who want to understand the business case around them.
What is DevOps it isn’t a tech knowledge or particular platform it is a state of mind in a concept. It has become a bit of a buzz word since I put this talk together originally. Doing lots of monitoring and skilling elastic, deployments, that is not what we are going to talk about. We will go to the start and look at the basic concepts at the beginning of getting started with this.
It is not a technology, a cure all to all of your problems but it is process. It is a means of identifying problems before they happen and putting processes in place that stop them happening again. Using either straight up management or other pieces of software, to manage the larger development process. The operations that your developers do.
I like to think of it as investment that you are putting some time in now to save hundreds of hours in the future.
Yes so why is it important?
Developers, it is going the make you a better developer, going to help you understand to better collaboration with other developers, and avoid the risk of trying new techniques, the overall quality of your code, as you write smaller and smaller pieces of code across projects and tested in automated ways. So you are saving time writing more code and better code.
It helps you bring new people into projects quickly, a standard set of projects and tools that, so you can bring a new developer on to the project quickly, rather than hoking around looking for tweak that is can go wrong.
If you are a project manager it will help you deliver better work to your clients, so one of the things we do internally is we have an automated deployment system, so when we have something new to show to a client we can go from working on that locally to having that visible to them to display in a staging environment in about 3 minutes should we need to. So if there is a critical bug or a change we want to see, we can make the change quickly and promptly show them. It is great for very, very fast iterative cycles when we work with the clients that they will come back with feedback or a bug that needs changing quickly, can show them and put that in the issue tracking it is finished.
Finally for the WordPress Community, kind of what I am going to talk about today is kind of just really great development practices and development processes. WordPress I think has been missing this in a lot of our kind of agencies for a long time and it is starting to come along and people are doing more and more of it. WordPress developed a reputation of not being a serious content management system, just a little blogging engine sites. Once we put in scalable, more easily testable, we start to become a contender for larger sites and critical sites, DevOps helps us move the community to bigger and better communities.
Overall, how does it help? Collaboration between developers, co-chairing in projects and automation to stream things out when you are working on projects.
So first off, collaboration. As teams grow, more and more developers get added to projects, projects get bigger. But developer collaboration is hard. You know, if you are not using a system to manage this, there is a couple of different ways it tends to happens of varying degrees of disaster potential.
The worst way is a shared FTP server, you have multidevelopers, one is editing — both save the files, single page finishes faster, dev opens simple post, you have saved your work in the meantime, but your work got wiped because the latest takes precedence.
A little bit better, maybe you are doing it operate a shared server in an office, verbally kind of going back and forth, I am doing this, that. There is still potential for disaster to come there as peoples work gets overwritten, time is wasted, bla, bla, bla. But this is a solved problem and there has been software around for years and years to do this. It is called version control. Our particular favourite version is git. It gives us a great way to manage code. Lets us look at an audible trail of code. Yes. Excuse me sorry.
Like I like to do code as a shared resource on a project and it shouldn’t just be changed and messed with willy-nilly. There should be audible trails, looking who made changes to code.
The way git works a process called commit, you have got your projects, local version of it. Make some changes, you produce a commit from those changes that commit consists of just the changes you have made. So over time your project breaks down into a list of commits, when you layer the commits on top of each other, they form the entire project. As you like one on top of another on top of another. Changes editions, changes edition, removing. You get the overall project. The overall code base, so you can go back in time to look at any given point. So as a commit I like to think of a commit as a useful piece of work. Something that you can describe in a single sentence and get it out there and into kind of your central, central repository of it. That might be a big fix it might be adding a small part of a feature, so if you added like a custom post type to your theme, that would be a good commit, that is one discernible piece of work.
Commits are really, really useful because it gives us this time line that we can see. So every commit when layered up on top of each other forms a whole picture, we can go back in time to any one of the commits. If I wanted to go back to here, I can revert to that commit ID, without having to unpick all of the files, if we weren’t using version control and I decided that we are going to work on a new feature, I have got two ways, either create a back up of a folder, do my feature work in there, do all my new feature work in there, decide I don’t like my new feature work and throw the folder away. The chances are didn’t do that. Who has been in the situation where they have been working on some code base and or someone in the team has been working on the code base and they have made all the changes and then it wasn’t working and they didn’t have a back up of the code before they made changes and they had to start going through undoing all the work piece by piece by piece by piece to get a back to where it originally was before they started doing the work.
Version control help us go past that, I can revert to the good commit. We have got the concepts of commit. We have another concept in version control called merging and branches.
It is kind of the real power of version control is that it lets us maintain different versions of a code base, almost everybody here works on websites I guess?
But, how many, how often do you think of the different versions of the websites exist, where you will have a production version of that website that public is hitting. So that is a site that is active, maybe e-commerce store maybe taking orders. Maybe have a staging version of that site that your client is testing, that you are doing your work on to make sure it is all right. Doing your BugFixs in there, probably another version of that site, adding a new feature or continuing to work on stuff that is not ready for the client. They are 3 different versions of your code base, software, 3 different versions of your website. Version control branches help us to manage this.
So we have got a little sort of example in that we have got a master branch and we are doing commits so we commit, commit, commit, commit deploy. That is fine. It is only one developer working on the project, we don’t need another branch, we keep, commit, commit, fine. What we could have done instead is create a new branch when we deployed, we did this to make sure that our master branch reflects what is in production and there is a good reason for that. I will show you now.
So disaster strikes and we find a massive bug in our branch. This is not taking store or payments, that needs to be fixed immediately. So the version control, if it is just a single branch we could revert back to where we did the deploy, we have the commit ID, excluding some of the extra work we have done. Because we branched here, we have that as a saved point in the code. So we can create a new branch from that, our big fix branch, make that BugFix, test it, check it, merge it back to master, so when we merge we take the changes that happened in this branch and push them into the master branch and deploy that again.
So now we have the BugFix code in the master branch deployed into production, the site is taking payments again. We still have a problem in our develop branch where that bug still exists so what we can do is then merge master back into develop. So it has the BugFix, so we can do all the testing we need there, to make sure that our new features work with our BugFix. We continue to work on our new development branch until it is ready, that is merged into master and deployed again. So again, master always matches what is in production.
Then the reason for that is if we ever need to make an emergency change to a branch of something in production, we have access to that code base easily, quickly without having to do other work.
We can add another layer of complexity to this, say we bring in another developer on the project, working on something specific. Commerce example. Perhaps working on a membership to the site. It is a big piece and risky, different ways of approaching it, we want to work on it independently, create a new branch off of develop called future X. The developer work withs on it, commits, commits, commits, commits, misses the dead line we were going for to get it to our major merge and deploy on the develop branch that is fine, keeps going, keeps going, eventually when it is ready to be tested gets merged to the develop branch, QA, tested then that is ready to be approved merged to the deploy branch so it goes on to, on to production and accesses to the world. So I will take a wee drink.
So to move on to code sharing.
Every project has code that people didn’t create in it. Everybody project has code that people didn’t create in it. So all this and it is called dependencies, everybody in the room massively dependencies, how many have …
This is quite an important distinction this is not like a WordPress project, you are building a site of which WordPress is a component. But WordPress has its own dependencies, there is software inside of WordPress that they didn’t create. Using libraries to do particular things. You have got some examples of this, dif which powers the editor, MP 3 tag information, BackBone and underscores, java script libraries that do the interactive stuff on the admin Panel. Those are quite, those are developer ones, libraries and stuff but php mysql, the independent versions of this, they are independent pieces of software that WordPress depends on to run. In turn are written in C, which depends on other libraries on your server to run as well. Dependencies all the way down. We won’t look at the php side of it but software, other libraries of code that other developers putting together. The problem is dependencies, they can change. If you write software that relies on other peoples software it is inherently risky, we have got a bit of a push in WordPress to always be using the latest version of everything, update X, Y always use the latest.
But that is not always a great idea. As versions change and increase, features get added and features get taken away. New bugs get introduced, bugs and things that shouldn’t have been in the library, that you were relying on get taken out and fixed. End up in the group situation where you are relying on a bug. When your versions change, if they change unexpectedly without you noticing, the whole thing can come down. So, what about within your own project? Already mentioned WordPress is a dependency of your project but if you are using, if you are building a theme custom theme for a client that theme probably depends on plug ins. Depends on word press, depends on other php libraries to do particular things. If you are, are doing some XML parsing or some other kind of utility library you are using to make it work. These are all dependencies. But the problem we end up having is that your dependencies in turn have dependencies.
So, again to go back to our theme example, this is kind of a java script one, if you want to use masonry, to produce one of the lovely block layouts in your layout. Masonry, depends on images loads, on jquery and events to run properly, underlying changes in the libraries can screw up masonry JS and which will screw up your theme.
So we have an example of a time when we built our site, debranded to protect the innocent.
So our dependency management completely broke down during the process of building this site for a variety of reasons, what happened was, this site was originally built on WordPress 4.4. Updated to 4.5, no problems, updated to 4.6 and the whole thing collapses. Reverted it back to 4.5 everything is fine.
Go back to 4.6 whole thing collapses again, so something has clearly changed as we move to 4.6. So we could have just pegged the version that it will always run at 4.5 and use the patch updates, the client didn’t want to do that, that is fair enough.
What happened? In WordPress 4.6 there is a new library added, — … is laughing at me — that is fine, introduced into WordPress, what happened was with us, was that we were using a library called twig that does templating with a plug in called timber that controls that. Because our dependency management broken down, all to version control, including the dependencies, they are little things that help us develop the site. The developer dependencies wpci, it also includes the request library, in an earlier version, because it was loading earlier in the system, php was assuming that is what we wanted to use, when it made a request to something it looked for a method that didn’t exist. The whole thing happens.
We had that remove all the extraneous dependencies, it could have been avoided if we had proper management in place.
You might be thinking, this all sounds like a nightmare and you are right, it is, I hate this, I hate having to like be sure that I have got the right version of this library and that library. There is a way of working with this and it is called composer.
Composer is the php dependency management package manager, basically lets you run a few commands in the command line terminal to add new packages to the project, a JSON file, that lists the project and then installs them every time you need to do deployment or want to do a rebuild of the project. Allows you to peg things to particular versions if you do update something and break it you have a logable audible list of here are the things we know this works with. So get back to here, at least get things running again.
Composer and WordPress don’t really play hugely well together we like to break out our packages as composer calls them plug ins, we list them out. All the different libraries on the external tools and things as part of the composer json and let them install it. The problem is it gets something from packagist, some clever people wrote a clone of Packagist for WordPress that lets you install things from the WordPress plugin repository via Packagist so that will let you access anything on WP.org. Maybe you have custom or pre purchase plug ins – some very clever people wrote a plugin for WordPress called SatisPress – our own {inaudible} owns as part of the maintaining team. So that let’s you sort of upload your own version of things you can distribute that and access it across your various projects.
Composer and WordPress don’t play well together at the moment but there are very interesting core tickets about getting an auto loader into WordPress which is part of composer and making it a composer package which I think there is going to be a talk on later on today as well.
If you don’t do a lot of PHP development and are more of a JavaScript person then Bower is something similar. Bower installs masonry, it’s clever, it knows masonry requires 3 or 4 libraries I mentioned, goes and installs them all and manages them and I don’t have to worry about it, I know you want masonry. It deals with the underlying part of that.
Dependency management because it relies on often external internet connections can bite you if you get say S 3 going down then you can’t build your site or if somebody removes something you depend on from public access.
There is a very famous things where leftpad, a node library, got removed from MHM so when people went to build their sites their applications again that day for a new changes and things to get out, everything broke. It is a really tiny library but was used everywhere, a great utility. So always be prepared, always have a back up, always have a cache. A couple of easy ways to get started looking at version control and dependency management start to break your own reusable code into independent plugins and share them across your version versions of those, across your site, across your project sorry via composer. So a couple of examples of that is if you look at the Powered by Coffee hub we have a drop in drop into virtually every project that writes all of our WP mail through mail gun. All you need to do is add WP config variable and that’s fine. We have something that is accessible, XM LPC across projects but we find it preferable to work this way rather than copying stuff back and fore between projects because we can control the versions like in this project we’re using version 2 of our mail gun thing but in this project we need to use version 3 and it let’s us get track of that mental overload and burden of being this project has version 2 so let’s copy it out of there and this project has version 3. We have a stated version, a stated accessible version of that we can use at all times.
So the third thing we’re going to talk about is automation. Automation is incredible. It can cause a lot of problems in the wider world and there is a political discussion but it’s not for today. Automation is great because repetition sucks. If you are a developer, designer, writer, PM, business owner, you are a creative smart person and you probably don’t like to do the same thing over and over and over again. It’s really dull. It makes people unhappy. It’s ultimately part of what can cause people to move away from jobs if they’re unhappy in their workplace because they’re just not doing something that excites them. And mistakes get made. Whereas often times tiny little things can be scripted and things that take a couple of minutes to do every day or things that are easily forgotten to happen can be scripted and make it happen. So need to do it twice I think you should automate it.
A rule of thumb for me is if it takes 2 minutes and you do it twice a day you should look at automating that so that’s 4 minutes a day, 25 minutes a week, 2.5 hours – it adds up over time.
And there are some really good candidates for automation. Deployments, which I will talk about a bit more, compiling assets which is something a lot of you are already doing if you are building your themes using sauce or less or stylist or coffee script you are probably compiling these assets down automatically using something like SAS and watching the files. Image optimisation everyone knows you should optimise images but it often gets forgotten so why bother, just write a script that will watch the folder and do it for you. Setting up servers we’ll talk about in a bit and installing WordPress. WordPress is a 5 minute install. I do it may be 3 times a week for various bits of projects. With something like wp-cli that is down to 35 seconds so a big saving there.
Let’s talk about deployments.
I hate ftp – I hate it with the fire of a thousand sons {laughter}. Every time I open ftp it is a bad day. Something very, very wrong has happened if I have to open ftp. Show of hands who has had a site deployment go badly wrong whenever they’ve tried to do it over ftp? A couple of hands at the front. My 2 favourites is when it only decides to up load half a file and spits out code every time someone uses the page or more insidious half a JavaScript file so you are in the Panel and suddenly stuff stops working. Nothing in your air log but gravity forums doesn’t work and you can’t edit anything. That’s a nightmare.
So because I hate ftp so much that we work to do automated deployments.
No more slow field ftp transfers. It easily ties into our version control. If we make a change to our develop branch that can be automatically deployed on to our staging server without anyone worrying about it. Same as production if we change our master branch deployed in production without anyone thinking about it saving more time, stuff we don’t have to think about, don’t we want to think about, tough we have automated so we don’t have to worry. It’s easy to undo a mistake. If a bug gets into production our deployment let’s us roll back to previous our version quickly so disaster recovery time goes from half an hour to 30 seconds because rather than try and debug it we see what is wrong and roll back.
To do our deployments we use an open sauce tool called Capistrano. Capistrano is scriptable and self installed, written in ruby, and like WordPress it’s sort of set up around tasks. You’ve got these various tasks as it goes through – deploy start, deploy finish, finishing, rolling back, and you can write new tasks that hook into this so you can script it to do whatever you want over time.
One of the things we do is tell it to compile our assets. We try to not commit to our version control our CSS files, we commit the source files our dot SAS files and whenever we set up the server do a deployment it regenerates those in their optimised versions that are all minimised as they need to be.
It is incredibly powerful and flexible and we’ve got a standard set up we use on every project. We just need to go in and tell Capistrano how to log into various servers it needs to. Often production and staging and if you are running it on multiple servers it can set it up to deploy to 100 servers at once if it needs to be.
It’s quite hard to set up. You need some experience but there are alternatives. Deployable, Buddy and Deploy HQ. These are SAS applications where you give them their server logins and it works the same way. All these tools you give them a log into your server tell them to do the same thing, they log in, does pull from your version control to get the code it needs and run the tasks you tell it to run. These are multiple different ways of approaching the same problem. These are nice GOIs you pay for to do it Capistrano is hard to use but very customisable.
So the next thing we want to talk about for automation is getting rid of a whole class of problems through standardising environments.
Who has ever had a problem where they have built a site or a site that their agency or team has built, works fantastically in local, works fantastically on staging then it comes to launch day, you deploy it on to the customer’s web hosting, the whole thing collapses and doesn’t work? Yes. Handful of hands going up around the place again.
We used to have that happen regularly. One that would always get us is MySQL versions changing and there being incompatibilities between them and various versions of WordPress, UTF – MB 4 changes? No …
By standardising environments we can stop this happening.
We want to use a virtual machine to make sure that everything always matches on every environment that is going to be deployed to.
My preferred way of doing this is controlling the hosting because then we can build something tightly integrated and know exactly what we’re building against but sometimes we don’t have that luxury, sometimes the client has their own web hosting and they’re tied in do legacy vendor so in that instance we’ll find out everything we can about their hosting and build a virtual machine that matches it exactly.
So if you don’t know what a virtual machine is it’s specifically a little fake hidden computer that runs on your desktop or lap-top as a virtual version of itself. An example that’s common is something like parallels that runs on a Mac to let you run windows except we use it to run different versus of Linux on our Macs; this one is running 3 separate VMs for the minute for different projects I’ve never got round to shutting down.
So the way we want to run our virtual machines is we’ll find out everything about that system that is going to be deployed upon, come back, match it in the staging environment then match it on the development environments. So that we have these scalable repeatable systems.
So to do that we use a tool called Vagrant. Vagrant is okay. Vagrant exists purely so people don’t have to use a tool called virtual box. Vagrant is CLI to virtual box and virtual box takes care of creating virtual machines for you; you feed it a disk image of the operating system you’d like it to run and it goes off and does that and it can be as quick as Vagrantup. A couple of minutes later and you’ll have a VM running that has most of what you need on it.
That’s only half the story. We’ve got the operating system. We’ve gone to centre west or red hat or whatever we need there but the other half of the story is matching all software versions so if we have a particular version of PHP we need, have a particular version of MySQL we need, a particular set of extensions to PHP we need, we need a way of installing all of that. Because I only want to do it once, I’m going to script that. I’m going to use a couple of tools. We use Ansible but Chef and Puppet are great as well. They’re task based; you feed them a list of things you want them to install and they go and install them, so it becomes re-useable. So if I have {inaudible} running on this Mac in front of me, I can use Ansible to install PHP 7.1, MySQL point 2, running everything, that’s great; we’ll then use exactly the same script on our staging environment to make sure they exactly match and because we base that on the clients version they will all exactly match.
I am quickly running out of time so to conclude this is going to take a while if you don’t know too much about it and you’re trying to learn it will slow you down to start with but when it saves you, it will save you big, you will save hours and hours when this eventually saves you. Take the time get to learn it and know the best practices and absorb it all.
Furthermore, these aren’t strictly WordPress skills. These are professional development skills. Every software development agents in the world kind of works like this and if we pass on that and skip on that then we miss out on helping ourselves be respected as developers but furthermore WordPress won’t be around for ever and there are a lot of WordPress developers in this room {laughter} – yes, fair enough like. A room full – technology comes and goes. Like people never thought that VGA would go away. At the time it was perfect but it’s eventually on its way out everything will go eventually.
Where do you go next? are you going to be unemployed because you learned to be a WordPress developer rather than a professional developer? Think about that.
Finally where to go next. If you want to learn more about this some topics to look into are automated testing, visual regression testing. Visual regression testing if you make SHS change you can {inaudible} BBC multiple screen sizes and compare them visually so you can see if you’ve got unexpected changes. Coquality checks. To make sure people don’t commit bad code and stuff against your style guide and doing notifications and things like that so everyone knows, like pushing into slack and stuff like that, so people know when you are working and when your deployments are done.
That’s me. I’m getting time up notifications so I’m going to stop there.
{Applause}.
SAM: Thank you, Stewart. Do we have time for a question or do we want to go straight to break? Has anyone got an urgent burning question that must be answered?
FROM THE FLOOR: Any hints on syncing database?
STEWART RITCHIE: There are some good tools for moving databases around. My tip is DB Pro. Obviously they have to be immutable; you move that entire database. You can move parts of it but you’re not going to move the changes, but I believe that same team is working on a product that does that like syncing versis for databases, mergebot.
SAM: Any other questions?
FROM THE FLOOR: I think it’s just an addition. Good to know you had the same problem with request. We destroyed the GitHub like with comments when we have that problem. You haven’t mentioned you also can install WordPress with composer so if you search composer WordPress on Google you’ll get the routes of your web-site and there is a way to stop from {inaudible} so when we deploy we don’t have WordPress on the server, just go via composer and everything goes altogether.
STEWART RITCHIE: We pull everything from Composer. We don’t use the roots IO stuff but it’s similar how it does it and there are great tutorials on the internet how to do it if you want to read more Google using WordPress with Composer.
SAM: Anyone else? We’re good. Okay. So now we have the first break of the day. Your nearest drink station is back through the way you came into the graduate centre and upstairs. There is a space called the junction and there is a bar there serving drinks.
While you are up there, there are sponsors up there. Please go and speak to them. You’ve got about half an hour to go and get some drinks. Talk to the people around you, people that are in the queue, get to know some people. And we are back here at 10 to 11 with Crispin Read who will be talking about object orientated user experience. Make sure you come in. Thank you.