It's actually easier to seewhen you actually try, but
Yeah, exactly.
Exactly.
So Paul is an engineering managerat a web agency specializing in
digital solutions for our non-profitand higher ed organizations.
Mm-hmm.
With nearly 20 years in the webspace, he's led teams building
high impact or press project.
With a strong focus on long termmain, that is maintainability.
I don't know why you can't say that today,and smart automation is passionate about
creating workflows that help developersgo faster and shift more resilient code.
So without further ado, everybody.
Alright, so, uh, let's get started.
So I'm inequality.
I'm actually, I havepromotion that I always,
so it's basically all my fault.
Um, as an agency, we kind ofhave two hands of business.
We have a support side inside.
Is that louder?
Okay.
How that good.
Okay.
So, um, and as you mentionedpreviously, I've been doing this
for a little while and I've beenwith CAN for just over 10 years.
So at Canopy we aim to be a trustedpartner for our clients, and part
of that is being able to shift highquality code and being able to do it
effectively across the whole team.
So that's not just for, um.
Getting code into production.
It's also for our developers spinup their contracts and get them.
So once we prove that we cando things reliably and well,
and that's how we start.
So to do that we need flexible tools.
So the key part of this is alocal development environment that
can replicate any kind of speedscenario that we're gonna get into.
So, you know, if it's Kinsa orWordPress engine, um, that's one thing.
But also if our client has likecommittee systems set up down to like.
Closet, we should be able tojust, uh, replicate that set up.
Then the CICD pipeline means weshould be able to, um, get that
code and test it wherever need go.
And all of that's maintained maintaining.
And then our delightful hosting partners.
So I mean, they are important because.
But in our focus and quality is kind ofeverything that happens before it gets
to the, that we really care about this.
So our tooling flow, um,we're gonna go through here is
our local development setup.
So we use a tool calledDF and Composer for.
And then we're gonna talk aboutsource control a little bit.
These are the most commonones that we use, but,
and then our CIC pipelines.
So we use,
and then our feature environments, whichbecome a key part of our test analysis.
And then finally the hosting,which as I mentioned before, um,
is important, but not really, butit's, uh, part of the pipeline.
So we gotta have that.
So, getting into it,we're gonna talk about
our developer team.
So local developmentis always kind of, but.
Um, mean back in the day therewas mail, um, and, uh, bedroom.
So we are doing, uh, docker basewith d Dev now, and because it's
Docker base that allows us to,uh, match any particular setup.
Provider.
So if they have Redis or whatever, we canswap out those tools and do that set up.
And onboarding adeveloper should be quick.
So if, uh, regular developer doesn't haveanything about red, they should still be
able to spin up the project and have thatthere and should be very transparent.
So when we do that, we have uh, in itcommand, and that will download all the
containers, download the database, andalso we bake them a file proxy so we don't
have to download uploads files as well.
We can just have allfiles there ready to go.
So a process that can take, uh, 20minutes just to download a upload
directory is now down to like fiveminutes and we install all the necessary
so we can easily refreshthat production data as well.
We'll have a command refresh,it'll integrate into the production
environment and our gateways.
And interface with our theme tooling.
So if we have a specific versionof node, we need to compile stuff
with web pack, maybe on an olderproject for using brunt or gulp.
That's all baked in into our entrance.
Yeah, and then it works with ourlocal customer tools as well.
So we're going to, uh, getinto the separate bit and
then it is flexible as well.
So if you have any other kind offirm that you need to do, you can
basically write any script to compile.
Say you have a whole bunch of Reactapps that are part of your website.
You can write a script that compileall of that and do very flexible.
Moving on to Composer, whichis how we manage all of the
plugins in core for our projects.
So we use Core as a package.
So this is how we would add, uh,core, this Guy John Block as Healthly,
uh, made an automated system topull in immersions before and
package, uh, it comes in very handy.
And then for our freeplugins, we use WP Packages.
And this is how we wouldadd, uh, a plugin to.
So the nice thing aboutusing Composer is we're not
files, so you don't have,
we're just c thereference, uh, in proposal.
So for premium plugins, whichare a little bit trickier, can.
Created a private packages.
So if we're working with a custom pluginthat is not publicly available, we
will put it into our private packagesand that's how we maintain our plugin.
So when another update for that plugincomes out, we update that packages and
it'll be accessible to all projects.
The other nice thing aboutComposer, it has commands.
So you can add custom scripts.
And we take heavy use of this as well.
We get into this, and so this is ourexample, command for running P-H-P-C-S.
We require p ps as a dev package.
And then here you can see in this example,we're referencing our custom standards
file and we're running it against the w.
So we scan everything and then if adeveloper wants to run that locally, they
just run CS and you can get the other.
So the other part composer that wedo is for patches, which is kind
of like the sweet sauce for me asa store developer, is you can also
patch plugins that you deal with.
So.
Because you're just storing areference plugin, you can then create
a path that, uh, just works for thatparticular reference that every time
that plugin is updated or installed.
That patch automatically gets appliedif the patch ends up not working
because it'll actually fix the issue.
Uh, you can go in and remove that.
So process will fail the patch.
And that's another signal.
So in this example,I've stored patch file.
Within the project, but you canactually also refer to like a GitHub
Diff URL or a GitLab diff URL too.
So if you have a pull request ona plugin, that's for on GitHub,
um, you can just work againstyour actual pull request as well.
So if you gets merged in,you just use and keep it up.
That's.
And then updating four andplugins, because everything is in
Composer, just becomes one simple.
Command Composer, update.
Composer will go and look for allthe latest references and download
them, and you can submit your,updated your files and that's it.
Um, the other piece of that is, um.
The build process will take careof the stalling and all that,
and we'll get into that in the,
so for source control, one of thekey pieces, not everybody uses it.
We work with a lot of support clients.
Uh, here it canopy.
And sometimes we run into clients,we're like, oh, and that's it.
Very sad.
So we always store code outsideof the hosting platform.
So one of the other reasons for thistoo is that clients like to switch
hosting platforms pretty regularly.
So if you're stuck within a hostingplatform, source control, um,
you don't get any of the extrapipeline, goodness that in ahead.
But then you're also stuck,uh, moving that code later on.
Move.
So we've standardized on, uh, but we'llwork with any common twist platform.
And our GI flow allows our team toscale and handle different features.
So we, um, follow kind of standardGI branching, uh, process.
So we'll have a feature branch and now,and this way our d developers aren't, um,
all working on the same single bed branch.
And then we also use GitHubteams to manage access to both.
So this comes in handy.
We don't allow all our developersaccess to all projects in the company,
so this is for security reasons.
Our Drupal developers don't need toall address code, and we also have
some data security requirements.
So if we set GitHub teams,we can control, which.
And following source controland this pipeline process.
When we work with client developers,which is very common these days too,
they can follow the same process.
Everyone is working from the samesource of truth, and the tools
are all the same, and they runthe same issues that do, which is.
So how do we actually enforce quality?
So the main thing here isthe GitHub status checks.
So this is a screenshotfrom within the GitHub,
uh, branch protection page, and we arerequiring the status checks passed.
So I'm gonna get intocircle CI here in a minute.
So we have um, some jobs that run CircleCI and we're saying that these jobs
have to pass on before we can measure,
and also I show this, but we domake sure that all PRS review
so.
This is what it looks like with theGitHub review and status checks.
And here you can see that we've gotour static code checks going, but the
deployment is still running and we'restill waiting for the lessness to run.
And then when we move a little bitfurther along in the process, this is
what it's like when all the status checksare done and we're just waiting for the
manual review from developer on the team.
So that kind of moves it out of thesource control and into the ci cd section.
And here, as I was mentioningbefore, we typically work ci.
Um, but we can go whereverour clients need us to go.
So we built a lot of tool aroundwith the CI to make it pretty quick.
But if you need to use GitHubactions or you can do that,
and we aim to automate as manyof these steps as possible.
So if you have some post deploymentsteps that need to happen for the
client, passions need to be cleared,tokens set, or anything like that.
That will all be bakedinto the deployment.
And where possible we aim tocreate reusable functionality.
Um, so the tools havedifferent ways of doing this.
CircleCI has this idea ofboards, and GitHub has GitHub
actions and the GitHub actions.
So both of those are opensource, which is great,
and.
CI ICD is also a great automation tool.
So if you have any backend reportingprocesses that need to be done,
you can use your CI tool to syncand trigger those processes.
So, for example, at Canopy, we havea bunch of hourly reporting that gets
done as our developers work on projects.
We dump all of that into BigQuery.
All of that code is.
Um, run and triggered three oh circle ci.
Perfect.
So circuit CI orbs.
We've open sourced, uh, ourorbs, so we have three orbs.
The first one is CI two, the slow.
Any type of job that we're runningwhere we need to install some
packages, we've got, uh, CI toolsthat install WP CI or Run Command.
Um, there's kind of a suite of separatethings that we can do within this
org, our deploy, or is the orb thatwe use to make sure we can deploy
whatever the hosting environment is.
So it's either our sync or get typicallyand know what the hosting platform is.
And then we have CMSupdates, uh, which are also,
so this is our stock test,which we run, um, outside of
our main deployment pipeline.
So here, when I was showing youearlier, the composer command
for running PH PCs, there's thatcommand line there that says pH PCs.
That's the composercommand that we're running.
So this is how we make sure thatdevelopers who are running HPCS
locally can get the same results thatare happening in CI because we need
to find them in a shareable spot.
And it's all running the same thing.
It's not running someother tool that runs HPCS.
So you can see we have the same sortof thing, so Dr. Vector and PhD scan.
The other nice thing about the org iswhen you fail, you will post that piece
CS report back to get a pull request.
So you can also look at it onthe, yeah, commit to um, and then
every time you push to your pullrequest, this runs every time.
So you like, you never, you neverdon't find out about mistakes.
And then when it comes to your CICDpipeline, this is kind of what it
looks like as a visual representation.
So there are workflows that aremade up of jobs and we have a job
for Cyprus or P and our deployment.
And you can see down here we'vegot our standard tests as well.
So basically our workflow isjust making sure that certain
jobs are hooked together and um.
One of the things you'll noticehere is that, uh, we don't have
anything before deployment, so that'sjust because of the screenshots.
But normally we might have a, like atheme compilation step because we're
not committing, compiled assets intothe repo whole, like conflict time.
So we compile that onthe fly before we deploy.
And usually that's a stack.
So the key part of this is, uh, kindof moving along the stack outside of,
uh, the static testing and the overallworkflows is feature environments.
So this is how we can get into, um,some functional testing later on.
And we don't want to be limited tojust dev test production environments.
We want to be able to createenvironments for moving forward.
So this is really important becausewe can, um, not have feature
clashes as developers work onvarious features on the same site.
So
you're.
It's all in a shared environment.
It turns into a hot mess for everybody,
and it also lets the clients review thedeliverables in a specific environment
that isn't related to handle work.
These feature environments also allowyou to upload any content for basically
our replication of production production.
And the key piece that I care aboutof this talk is it gives us a place
to run our functional tests against.
'cause these tests are reallykind of the value add in terms
of, um, what we can do for folks.
So how do we get a future environment?
So it does have on yourplatform, um, you are
using pathon.
Um, they have a baked inproduct called multi dev.
So depending on your plan, you'll beable to create a multi dev through
CCI or through the dashboard aswell, and that'll that you expand.
Future environment is hosted onyour infrastructure tooling, so
it's really great, very reliable.
And then the second one foreverything that is basically not.
Is Typo, um, which is basicallyanother Docker based tool.
So much like our localdevelopment environment to dev is
basically Docker, but for local.
Talk about is basicallydocker, but for the web.
So we can match any kind of productionenvironment, uh, settings that we have,
and also download the database to ourproposal, install, get the files, whatever
we need to do, and then it's exposed as l.
So this is kind of how we between,um, making the test environment first.
So once we have a testable environment,this means we can move on to
functional testing, whichis what we really care about
is static tests are great.
It's, you can have super cleancode, no deprecation warnings.
It's all great, butyour website can spell.
So one of the key functionaltests that we run is Lighthouse.
So going back to uh, an earlier thing thatI mentioned, we have our CI tools board.
And one of those teststhat we have is based four.
So every pull request, we'll geta lighthouse test run against it.
And what we do is we run threelighthouse tests and figure
out what the best score is.
And the reason we run three tests isthe performance score is the only one
that will never fluctuate, and that'sbecause of network and caching and
how your website is actually perform.
So we can dig into those.
And the other ones thereare, um, just baseline.
They'll always stay the same.
And then you might be wonderingwhat these scores are about.
So the 90 there for performance isthe score for that particular test.
And then our baselines.
So you might be wonderingwhere that baseline came from.
Uh, Google Chrome reportsback your website performance.
Business site and they storeall this data in what they call
from user experience report.
And that is the basis for whenyou run a lighthouse test, you
get the core web vitals, tells you
all that data is the aggregateof all the people using.
So someone else figured out a coolway of figuring out what the seven
fifth percentile is for all that.
So what that means in this particularcontext is that 75% of the websites
on the internet, their score is a 55.
So we want to aim for beingbetter than 75% on the internet.
So anything better than 55.
So we're doing okay onthis particular request.
Our SEO score is garbageand part of that reason.
Is because we're using a featureenvironment which has one great
add-on that's really crappy forLighthouse, which is that it always
adds a header to make it not,
or anybody else.
So that's a really big notein terms of lighthouse.
So developers, do you have to go in and.
Take a look at the report andsee if there's anything else
that's, uh, going wrong there.
Um, yeah, so that's whyHouse is pretty important.
That's probably one of the keyfunctional testing tools that we use
in Canopy, um, track of how to do so.
This will be integratedinto every build and every.
So another functional testthat we'll add is backstop.
So this is a original compressiontest feature and as you can see
from the screenshot there, it'llhighlight the differences between a
reference site and white group is.
So this is what our featureenvironment is built, is the test site.
I can see that some of the thumbnailshave changed, um, and that's fine.
Nothing else is, uh,really broad from there.
So one of the kind of tricky thingsabout a backstop or any other visual
regress tool is you need to knowwhen to put it into a project.
So if you're working on a buildproject with the front end is changing
all the time and your reference siteis changing, or you have developer
that's like you built the header fivetimes, but you're just gonna create
a lot of testing noise for yourself.
So probably don't add it at thebeginning of the bill code check,
but if you have a long term supportclient, the design is very stable.
You can add that and with anextra check, um, just to make
sure anything in a serious way.
And then the next big, uh,functional thing that we're gonna
get into is Cypress testing.
Socy testing is stillfairly new at Canopy.
And it's a end-to-end framework forkind of test user flows on websites.
Uh, it does a little bit more thanthat as well, but we use it for the end
end testing and we expect our cypresstest to run locally and against our
practice, our CI pipelines, we willsupport that as well as our, uh, lo.
For people,
and this is just an exampleof what that looks like.
So we're getting a a button andgone and clicking that button and
it's kind of like very simple syn.
And then another key part of Cypress,because we're aiming to build
components, is that we have support.
So this is a way of doing a lot ofcomplex operations that you have to
do a bunch in a repeatable fashion.
So, for example, if we need to loginto WordPress, if you imagine the
steps that would go take to go intoWordPress, you have to go to the
login page, find the form, fillingusername, filling your password,
submit, maybe check for the cookie.
That's a lot of codes.
Copy and paste across maybe a hundredtests that you're maintaining.
So you create that login commandas a support command, and then
that code is just in one spot.
So we have some support commands, I'llsay that mostly convert based right now.
And we have open source.
Ours.
Please take a look and, um,submit all requests of issues.
Working the jokes, I guess.
I appreciate it.
Um, yeah, so we're gonna get into how,how that all looks in a little bit here.
But
as I was saying before, surface testingis better and static testing your
code can be perfectly clean and yourwebsite is still work in some scenarios.
So when you have a donation flow,you work with a lot of nonprofits.
Um, and your donation form doesn'twork, but it's not flagging,
um, in your static tests.
Like this is a way to ensure thatour donation process for your client
will work with every code request.
And the nice thing too is ifyou have a hundred tests, you
can run them in parallel and
you run those tests in parallel.
Um, and that really helpsspeed up your CI process.
So if you're writing tests individually,you can test them locally, individually,
but if you have a hundred tests,reading 20 minutes for tests, run.
Um, and uh, so that's just a littletrick that you can read into your, uh,
and we're just gonna get intowhat a support command looks like.
This one is one of theshorter support commands.
So here we're just setting thetable on end page and, um, you
just see where like five and block.
And then we're clearing new textthat's already in there, and we're
passing the review under table today.
So when it comes to sticking allthis stuff together, this is what
it might look like for an actualtest for creating a basic block off.
So here we're finding some constantsor content that we're gonna create.
And then we're using a bunch ofthe support commands that we have
to go and fill out that edit.
So why this is important is you may beworking on a specific feature, but, or
you may have added a plugin and you may befocused on testing that specific feature.
But if you have a suite of surfacetests that are going and testing the
basics behind the scenes, you don'tneed your QA to project manager.
So another unlucky developer thatgoes through and has to like click
around the whole website anyway,just to make sure that is not broken.
We have the results forus, um, which I love.
So here you can see we have, um.
Some support commands when you visitthe edit page in WordPress, there's a
million Ajax requests that get fired off.
So we had to do this supportedit page, but here we go
through and we add some content.
And then the key point too is it test.
So we need to validate that,uh, that conversation was there.
So after we publish, um,we go and we look for that.
So I've got.
It be what this looks likefrom the local side when
when we do this.
So the nice thing too is everyCypress task will generate this.
So we just logged in automaticallyand we're starting the content.
So if you can imagine a PR runningon our future environment and we're
validating the basic functionality ofwork tests working, plus any project
specific functional tests run thatdonation flow and e-commerce checkout,
um, we can handle all of that through.
So this is really testing.
Four piece more than just seven.
So these are the index request for here.
So you scroll down and that waskind of, you can see the green
check marks there at the end andscroll down and see the uh, images.
So that's kind of what everysite test should look like.
And in certain CI you can go andyou download the video, the real
test, so you see exactly where.
Alright, so moving on
is my dream as I work in support.
And it's all over the boat.
Um, so my dream, uh, the guy presentingin front of me was like, I hate support.
Guess what I love.
So, um, Kennedy does a boatloadof support, actually almost
50% the support agency.
Um, and my dream, because we have about100 objective support panel at one time.
Is automated updates, loves doingmanual updates to a million press sites
so we can get the robots todo it for us even better.
So before, as I was mentioning,all of this kind of, and telling
each other because we're running.
Storing or plugins in our code withComposer, and we can now run Composer,
update and all of that for us.
We go back to our CMS updates boardand a few slides ago, and what
that does is it'll spin up a localcopy of that site, run, composer,
update, and create a PR for us.
So then we use our CI pipeline.
Which runs on the trigger.
So every two weeks, every week,however often you do it, you really,
you can do it, that's the thing.
Um, you'll spin up a PR with any updatesand if there are no updates, so this
makes it really handy on your managing.
And then the key piece is we haveconfidence in that update because
we have all these tests running.
So if we have our Cypress test runningthat our donation flow is still
working, then we can be confident inreviews, wash, merge, and deploy with
the rest of, so what that looks like.
So, yeah, that's my dream, whichis really sad, but like lie.
That's true.
Um, and then what that looks like fromlike a Circle CI perspective is our CMS
updates or here, and we're targetingWordPress and we're pulling from the
live environment for the database.
So takes care of dealing with.
Where is the data coming from?
Pulling the database fromthe correct environment.
So it's down, it's down to seven.
These few parameters, they don't haveto deal with any of the like server,
and we're justifying our method there.
So this is part of makingit reusable and easily.
So what's this conscious?
There's always some, I'm not gonnasay it's all business all the time.
Um, one of the things to look outfor is you need to set service
account for all your tools.
Um, you need an accountfor your robot, basically.
So when I get fired for giving a badpresentation, all the projects I've
set up with my keys and my access don'tstop working because we've set it up
with our canopy robot account and not.
Um, you need to make sure you'reincluding, uh, rotation, tokens and
keys in your overall dev process.
People come and go in an agencyand also there are security issues
and there's security to rotate.
Um.
Whatever the frequencyworks best for your agency,
developers need to payattention to the tests.
So, I mean, I'm excited about tests.
Not all the developers that workwith me are excited about tests,
so developers can be like, oh,this test has been for months.
I'm, it's always failing.
That's.
So kind of changing that mindset,it's like, oh no, it works.
It's fine.
It's like again.
Um, so it's kind of someeducation, depending on diligence.
You need to be realistic about howmuch you can test on a project.
So our, you know, small supportclient who basically just there
for updates is not gonna get a fullregression testing suite with Cypress.
They might start out with statictests, and as we work with them
over time we'll start adding more.
It's not like from dayone you get all this.
And this stuff is really hard.
So, um, there's a lot of moving piecesand, you know, developers want to focus on
the thing that they're passionate about.
So our workplace developerswant to work on workless.
When tugboat stops working orsurface ci, getting them issues,
you're like, uh, what's going on?
So you do need to be mindful as wellthat you know, carving out some time
to have some people that are focused onhead ops can go and fix those issues are
really important because it's supposedto be in an enablement for your team.
And when that enablement stopsbeing an enablement really proper.
So we're almost done recap.
All of these tools here when weset them up are kind of both on
topic top of each other, so ourdevelopers should be able to, um.
Work on a production like CottonLocally and manage everything with Moer.
How going forward, all the.
And then we want to separate thetools from the final platform.
So you know, we have Circuit ci, whichis separate the tool that can be on.
Um, and that makes it all portable.
So principles portable,and we need to keep our.
And once your team really gets intoowning tests, it's pretty awesome.
Um, so when they're paying attentionand looking at all of this, the quality
of the final product gets better.
Um, and the clients cantell the difference, um, as
functioning work a lot better.
And.
Any
get you guys out on time.
We do have room for meetingone or two questions, but Okay.
I'm gonna go ahead andgo a question right away.
I'm assuming you're also available.
I,
I'm available for all the chats.
Okay.
Um, one thing I.
Sorry, one of the slides you havewith the seven minutes, is that
unusual with all these tests?
No,
so this is depending onthe hosting platform.
So that was a hosting platform that,um, there in a, of a multi environment.
So when the infrastructureis slow, then the.
And there are only somany things that we can
One more.
Okay.
Yeah.
So is the question adding securityanalysis into Yeah, so we had not.
We up until very recently, connectthe standards analysis tool.
Um, so we actually just have, so it'snot part of the standard slide tool,
but we are going to be adding it.
So every project gets analysis done.
And we
that, right?
And one of the other thingsthat we can do too is run a
security against the environment.
Some other tools as well.
And that is gonna wrap it up for thefirst section of day one and coming up
is the keynote, but before that we havea half hour coffee break and apparently
there's some cypress talk tomorrow too.
I heard where on the street is.
Yes, I will be at the Cypress talk.
So
otherwise.
Go into the after party tomorrow.
Go and enjoy some coffee.
What, sorry, what were we doing for
after party?
Thanks everybody.