Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
hey everyone I'm my name is Graham Taylor these are my colleagues this is Elliot to my left and Andrew everybody here you you probably just like hit the jackpot because not only do you get to your one talk you get to hear 3 and 0 if I leave like after
I've done my bet it's not because I don't want to answer your questions it's because there's a scheduling clash and I'm actually meant to be presenting downstairs as well I can clone myself in time at the behat lab so if you do have
any questions for me then we've got a stand come and see me but hopefully these guys will be able to answer your questions if you happen um so let's get started who are we so we all work for cap gemini some of you probably know capgemini i guess most
of you probably do a bit of large multinational organization we are have we do drupal that's only a small slice of the pie and organization as you can imagine but it is growing most of our Drupal projects at least the biggest ones are based out of the
UK but we also have Drupal teams in France and India Belgium Sweden the Netherlands in the UK we around 30 drupal developer strong and yeah we have a stand here as I mentioned before we've given away kazoos so come along and give us a tuner because they
will record you put on YouTube you can win some prizes and so what do we do here are some of the clients that we work with our biggest project in the UK is the Royal Mail which also includes parcelforce and the post office websites Royal Mail just to give
you some stats on average is doing around 21 million Commerce orders per year our next biggest project is probably Eurostar which is averaging around two million in revenue per day so obviously as you can see we do big sites I'm going to talk a little
bit about building a scalable developer workflow so let's drill into that a little bit the first thing you'll need is developer obviously if if you're doing things that scaled it's likely you're going to have more than one so you're
gonna have multiple developers first thing I think is that's really poor important is that you have the right people on the bus and the right blend of people as well so you need to decide do you need three senior developers one mid level one junior test
or business analyst it's really important that you have the right blend of people in your development team and because it's really important to get off on the right foot I've seen project starting were basically massive project start more developers
arrive on day one it's just lots of other people other disciplines so not not really any technical people on the project at all things the decisions are being made things that can get out of hand you should always have a technical input I believe at the
start of your project I've also seen other project we have like many junior developers the blend isn't quite right and again think things don't exactly get off on the right foot and you kind of end up with a Barban or things that you need to fix
while the projects in flight which becomes more difficult aside from having the right people on the bus you also need to make sure that everybody has what they need to do their job so make sure your development team is tooled up make sure they are a comfortable
environment like all these things are fairly obvious right these are some of the tools that we use it doesn't really matter what you use as long as you know what you're going to use and as long as you have everything you need when you start project
so yeah we use in phpstorm XD bug that was really important for your developers get every developer get them set up properly with a development environment so that they have everything they need and everything at their disposal to work properly the amount
of times I've had to help people get set up and because if not quite able to work as productively could of so make sure that's really important make sure they have everything so back to the back to the I've talked a little bit about developers
and what you kind of about bland people and what they need so let's talk a little bit about workflow so the first thing is communication it really is key it doesn't really you can have the best workflow in the world but if nobody talks to each other
things will fall apart so make sure you have you decide on your communication channels like a are you going to use skype are you going to use IRC and you're going to have regular daily stand-ups how your projects going to work make sure you decide on that
all up front and you know how you're going to communicate with your developers and with your client and how that how you can bridge the gap between your developers on your client as well yeah and don't run before you can walk don't promise 1 million
things to your client on day one I don't sell a project on the Friday and expect your team to be fully up and running on the Monday if you can what we try and do is as have like bootstrap iterations where we go in and tool up and set up and that may last
for weeks it may last eight weeks it depends on the size of the project but make sure i would recommend you to do this and spend time up front with your development team to make sure they have the processes and tools in place to do the job properly because
it'll make your life a hell of a lot easier if you try and do these things mid-flight it's painful clarity of purpose if your team this is really important you because your team without knowing how to do anything nothing will start and without knowing
what's done you'll never finish without knowing what's good you'll inevitably end up taking shortcuts and your approach are just to get the job done so the team really needs to know how to do things well what it means to get things done and
what good looks like so i guess if you're going to set up a developer work for the first thing you're going to need is version control i'm probably telling you all to like suck eggs is great obvious most people nowadays use get but you can use
svn if you want or you can use something else but i'd recommend get because pretty soon what's going to happen when you start building things and especially if you're doing things at scale as well what what you're going to want to do is have
lots of things happening in parallel for example on the Royal Mail project we have a larger development team which at the moment is about 20 developers that's all split up into like sub teams within the larger development teams that we have about six streams
are like six sub teams of like maybe 436 it depends on what the nature of the work is and they're all doing things in parallel so one team may be doing effects with new features one may be doing box fixes one may be doing enhancements but that's all
happening at the same time and that's all coming together in the end I'll explain a little bit about how that all comes together but yeah version control is really key so you can you can have branches and lots of things happen in parallel and for workflow
like you don't need to reinvent the wheel before like you'd get workflow so example we use the get floor workflow we find it as a good fit for us but check out link there's other workflows and they're really depends what how you want how your
project wants to work pick one that suits you but I would advise not to invent a completely new workflow pick one that's already established and documented on the web standards this is kind of links back to my clarity of purpose like your team needs to
know how to do things and what good looks like so we already have these things available the drifting triple coding standards your team should follow those if there are in Drupal modules I mentioned on the tools page that we one of the tools we had there was
phpstorm we like to use that a lot if you check out those two articles that i'll give you help to get your IDE configured properly for the triple projects so i'd recommend like I love PHP song but I'm not going to get into like ID wharves and in
this session but yeah if you like you should be trying to check those out make sure if you want to use it get your developer set up get them all set up in the same way and I'm so it's easy people can help each other people can pair program together
it just makes up those things a lot easier and then finally commit messages so yeah check that link make sure you commit messages basically they know don't assume that the reviewer of the code knows what the original problem was and in your commit message
make a descriptive about why etc it's actually called review so this graph I'll explain it a little bit the top the top graph is the percentage of cord committed over time that has been reviewed and the bottom graph is the number of bugs raised per
week over the same time period and this is like a graph they're from one of our project as you can see as more quarters being reviewed we have less box always make sure that you do code review it's the same for like drupal 8 right any patch can't
get into Drupal 8 without being reviewed by at least two other people so a core committer can't commit it until it's been our TV seed by at least two others for code review we use crucible which is a part of that lasting stack but if you're using
things like github or whatever that's got code review tools bill n you can use other tools to like fabricator which is a Facebook code review to pick one fits best for you and review cold testing so if you i would highly recommend if you can to do either
[ ... ]
Nota: se han omitido las otras 4.862 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.