Artwork for podcast Tag1 Team Talks | The Tag1 Consulting Podcast
Static Site Generators at VA.gov: Metalsmith, Gatsby, and the Future of Static Sites - Tag1 TeamTalk
Episode 7414th July 2021 • Tag1 Team Talks | The Tag1 Consulting Podcast • Tag1 Consulting, Inc.
00:00:00 00:38:30

Share Episode

Shownotes

The VA.gov website serves critical functions for those who serve our country.

Built on #DecoupledDrupal and #Metalsmith as a #StaticSiteGenerator, the Department of Veterans' Affairs website is one of the most compelling and robust examples of a powerful decoupled #Drupal architecture serving #StaticSites and #Jamstack-driven deployment. Plus it uses #GraphQL to mediate the back-and-forth communication between Drupal and the VA.gov static site.

In this Tag1 Team Talks episode with Preston So (Editor in Chief at Tag1 Consulting), Michael Meyers (Managing Director at Tag1 Consulting), and special guest Neil Hastings (Tech Lead for the Core CMS team at VA.gov), learn more about how the VA.gov website offers functionality not just for its core users but also for content editors and even outside developers, thanks to its open government focus and Lighthouse APIs for developer-contributed applications.

Transcripts

Speaker:

Hello.

Speaker:

And welcome to another episode of Tag1 TeamTalks.

Speaker:

Today is an exciting episode.

Speaker:

I'm really, really happy about today's topic because we're going to be talking

Speaker:

about static site building and static site generation at the department of

Speaker:

veterans affairs or the va.gov website.

Speaker:

I'm Preston So.

Speaker:

I'm the editor in chief at Tag1 Consulting.

Speaker:

I'm also senior director of product strategy at Oracle and also the

Speaker:

author of the only book on decoupled, Drupal, Decoupled, Drupal,in practice.

Speaker:

Today I'm joined by , Michael Meyers, managing director at Tag1

Speaker:

Consulting and our guest today.

Speaker:

Neil Hastings technical lead for the core CMS team at VA.gov.

Speaker:

Let's go ahead and jump right into this topic today.

Speaker:

Um, so Neil you know, I think static sites, right?

Speaker:

JAMstack these buzzwords have been coming up all the time.

Speaker:

so one thing I wanted to kind of dig at is I think a lot of people have been, you

Speaker:

know, hearing about this new, what I call kind of the second wave of static site

Speaker:

generators, you know, not so much the, the old days of Jekyll or, or some of

Speaker:

those older projects, but some of these new ones that are popping up like Gatsby

Speaker:

as part of the what we call the JAMstack.

Speaker:

So I wanted to ask what exactly is driving people towards this and why

Speaker:

would anyone want to use something like a static site generator, especially this

Speaker:

kind of new second wave that's coming

Speaker:

up?

Speaker:

Yeah, the JAMstack is really interesting and I, you know, used Jekyll in

Speaker:

the past when it came to the VA.org project The, the site being up all

Speaker:

the time is still mission critical.

Speaker:

Like you said before, it's mission critical application.

Speaker:

If we go down then a veteran could not be able to relay information

Speaker:

back into the hospital and not know where to go for hurricane comes up.

Speaker:

They rely on this information for a lot of really important information.

Speaker:

so people are driven by like the separation of, of front

Speaker:

end display from content.

Speaker:

It's just a natural separation high performance.

Speaker:

It's high, scalable, it's highly secure.

Speaker:

You don't have a PHP website, you know, delivering , um, in our case, we're

Speaker:

using AWS and S3 delivery, everything.

Speaker:

So we didn't have a web server.

Speaker:

I don't, I don't have 2:00 AM pages anywhere.

Speaker:

I'll have to get up and go, you know, bring the site back up.

Speaker:

Right.

Speaker:

It's always there.

Speaker:

So those are some great benefits we have with the static site generation.

Speaker:

And that's a really, you know, I think for all of us who have

Speaker:

experience with those pages, right?

Speaker:

I mean, I remember being on call 24/7 and having to get a page, you know, one story

Speaker:

I always tell this is getting a page and I'm having to go into a McDonald's to

Speaker:

get their free wifi and fixing up one of these active, actively running servers.

Speaker:

So static files are definitely, we, something that I think is

Speaker:

infinitely, scalable, right?

Speaker:

Cause they're just, you know, static files.

Speaker:

but one thing I wanted to do just before we jump into some of the kind of pros

Speaker:

and cons is, you know, the second wave of static site generators is kind of part of

Speaker:

this new model called the JAMstack right.

Speaker:

Java script, APIs, markup.

Speaker:

a lot of people are talking about it.

Speaker:

There's a large community starting to emerge around this.

Speaker:

but let's talk a little bit about what are some of the disadvantages of this.

Speaker:

And I think this also hearkens back to some of the disadvantages

Speaker:

that came up from the.

Speaker:

First-generation of static site generators as well, where there is a manual step.

Speaker:

Isn't

Speaker:

that right?

Speaker:

Yeah.

Speaker:

That's right.

Speaker:

So with any, you know, it's, it's a trade off, right?

Speaker:

So with, with that great scalability of those static HTML files,

Speaker:

they're static, HTML files.

Speaker:

So that's where a content being pushed.

Speaker:

You got to figure out how to get new updates out.

Speaker:

What is your build pipeline look like?

Speaker:

how complex is that?

Speaker:

How fast or how fast is content going to be published?

Speaker:

So a big piece we have at the VA is managing editorial editor expectations

Speaker:

of how long the content takes to get out.

Speaker:

our, our particular front end is driven by some static content, some React widgets

Speaker:

just kind of a, a mix of the, those two levels, the two different types of, you

Speaker:

mentioned we have kind of a mix in there.

Speaker:

There's definitely React widgets.

Speaker:

We have a public API was also a traditional static build in there.

Speaker:

so that kind of, that that's adds a lot of complexity.

Speaker:

And if any larger organization.

Speaker:

over time, we would kind of move from one, one level to the next level.

Speaker:

And as we go yeah, so our particular team, our particular situation also,

Speaker:

we actually have different teams that manage the different system.

Speaker:

So I'm, I'm on the CMS team, which we go up to the GraphQL, we use

Speaker:

GraphQL API, everything on the other side of the constant bill

Speaker:

is, is actually a different team.

Speaker:

We cross over from time to time to help each other.

Speaker:

Mostly it's CMS team going to the build side.

Speaker:

but at the same time, like I there's, I don't own that code so I can

Speaker:

do pull requests, the repository.

Speaker:

I, you know, my, my project manager, doesn't own that situation.

Speaker:

So we have two different teams.

Speaker:

I manage that.

Speaker:

So is that kind of.

Speaker:

Different team also, which is also an advantage right because you

Speaker:

can scale teams separately and you can build those out your, your

Speaker:

various specialties of skills.

Speaker:

You know, Drupal skills is different than a CSS HTML skill.

Speaker:

And instead of like having a Drupal person, who's also a

Speaker:

theming themer, traditional Drupal, themer, that person can be.

Speaker:

HTML JavaScript can do the coolest things with React and not have to

Speaker:

know, not have to know Drupal itself.

Speaker:

So that's kind of a mix

Speaker:

there.

Speaker:

And I think it's really interesting, Neil, you mentioned a couple of really

Speaker:

interesting aspects to this VA.org project, which I think really bear

Speaker:

mentioning, which is that you know, first and foremost, you've got a clean

Speaker:

separation of concerns between the people working on your content and those who are

Speaker:

working on the front end architecture, which is, I think one of the really big

Speaker:

advantages of, of decoupling Drupal or, or using Drupal solely as a backend system.

Speaker:

But then the other thing I think that is really interesting, that you mentioned is

Speaker:

that you're actually able to mix and match and, you know, not only use Metalsmith,

Speaker:

but also use React and put in some of these more dynamic components, which

Speaker:

I think is part of the second wave of static site generation that we're seeing.

Speaker:

Um, so one question I had was you know, I know that you all are on Metalsmith.

Speaker:

I used to work for Gatsby, so, so I've got some experience with that.

Speaker:

what are some of the other.

Speaker:

Static site generators or tools or frameworks that, that

Speaker:

you've worked with and that you

Speaker:

like.

Speaker:

Absolutely.

Speaker:

So I there's a lot of the more traditional first layer ones.

Speaker:

Jekyll a little bit with Hugo in the past.

Speaker:

Gatsby is definitely one we're evaluating right now and kind

Speaker:

of doing proof of concepts.

Speaker:

We're looking at migrating off of Metalsmith.

Speaker:

It's kind of an older we're in an older version.

Speaker:

they don't have things like incremental builds.

Speaker:

Gatsby's incremental builds stuff.

Speaker:

They just announced.

Speaker:

It's really cool.

Speaker:

we're really excited about that.

Speaker:

Incremental builds is the future for us.

Speaker:

Um, next JS is something we've played with a little bit.

Speaker:

we actually tried to implement tomb, which is a Drupal module.

Speaker:

that wasn't great for our use case.

Speaker:

So we rolled that back recently.

Speaker:

We're moving to, we we're moving to a different model, but those are

Speaker:

all ones we've used in the past.

Speaker:

They're all great for different situations.

Speaker:

yeah.

Speaker:

I couldn't agree more.

Speaker:

I mean, you know, I definitely use Jekyll and Hugo in the past.

Speaker:

They're both great, both solid.

Speaker:

but I agree.

Speaker:

I think some of the you know, I know that some of these projects like Gatsby, next

Speaker:

JS think Tome might be actually looking at this too, looking at kind of, you

Speaker:

know, how do we limit the amount of time it takes for these builds to actually

Speaker:

generate, because the time durations can be pretty long, especially for a site.

Speaker:

I imagine that's as large as VA.org, right?

Speaker:

Yes, that's right.

Speaker:

So our our build pipeline is very complicated because it not only pulls

Speaker:

in content from Drupal, but also pulls in some content from a old markdown.

Speaker:

That was the old version.

Speaker:

So they had.

Speaker:

Originally had a Jekyll site.

Speaker:

So the original site was a Jekyll site that content, got migrated the

Speaker:

Drupal, but not all the content.

Speaker:

So some of the contents in a GitHub repository, markdown files, some

Speaker:

of it's in Drupal, some of it's combining custom React widgets.

Speaker:

So the build pipeline actually pulls all this stuff together into one VA.gov site.

Speaker:

So on the VA gov site, I mean, it's, it's, I can pull up some analytics.

Speaker:

I was gonna pull it up via the Google analytics, but if I'm at look, we have,

Speaker:

we get millions of hits like a day.

Speaker:

So this is, it's a very high load site.as you would expect.

Speaker:

Our CMS.

Speaker:

we currently have around 120 active users.

Speaker:

We're editors, and we're going to expand, I want a thousand within the,

Speaker:

this year active editors on the site.

Speaker:

So that's a lot of stuff going on at once.

Speaker:

That's just, we have a lot going on.

Speaker:

and that the biggest, like we talked about a couple of times the biggest.

Speaker:

issue we're dealing with right now is the time it takes to publish.

Speaker:

So our entire build pipeline takes almost an hour.

Speaker:

to do you think entirebuild, end to end.

Speaker:

Before?

Speaker:

So getting the site to live?

Speaker:

so which, which is a long time.

Speaker:

Right now, we, we build twice a day to it.

Speaker:

So editors can only get

Speaker:

Our content from pupil live twice a day, the React widgets are live all the time.

Speaker:

We have a facilities, API benefits, information.

Speaker:

Those parts are live, live data from live API, but the Drupal content

Speaker:

is only published twice a day.

Speaker:

and getting that pipeline done is the biggest thing is the problem.

Speaker:

We're having right now.

Speaker:

We've, we've tried to address this in several ways.

Speaker:

We've improved a graph, QL queries, REFCO queries.

Speaker:

They used to do this one large one.

Speaker:

It used to take an hour just to run it.

Speaker:

Now we run it.

Speaker:

we've several, several small ones, and that takes about five to 10 minutes now

Speaker:

to run a build to get off the content.

Speaker:

That's just going to just going to continue to grow.

Speaker:

Right?

Speaker:

So without.

Speaker:

It, it, we have to do a full site rebuild every time we deploy our content.

Speaker:

So every HTML page gets recreated.

Speaker:

All the content gets pulled.

Speaker:

It's basically doing the entire Drupal database dump into JSON

Speaker:

. And then another system is processing that data.

Speaker:

Um, that's not super efficient, right?

Speaker:

So incremental builds is the future.

Speaker:

We have to go there one page at a time.

Speaker:

Um, but tons of tons of problems there, tons of potential, you know, complexities

Speaker:

there with dependencies of page, links and not just like links within

Speaker:

Drupal are one thing easy to manage.

Speaker:

But remember we said, this is.

Speaker:

Oh, it's content from all over the place.

Speaker:

So how do we know if a page on Drupal has content pointing to a

Speaker:

different content repository and when to update when so it's, it's

Speaker:

an interesting problem to solve.

Speaker:

Actually.

Speaker:

I love these kinds of things.

Speaker:

So I'm excited about it.

Speaker:

One thing that I'm hoping to see in the near, or, or maybe far

Speaker:

future is a way that we can almost.

Speaker:

make builds so incremental that they're streams to the point where, you know, you

Speaker:

know, anytime you save something in your CMS, it just kind of, you know, sends

Speaker:

that tiny little chunk over because, you know, Neil, you, you, you identified

Speaker:

one of the really core issues, right.

Speaker:

Which is that any website and by the way, but, you know, I have to make a correction

Speaker:

here because the show notes said VA.org, but we're actually talking about VA.gov

Speaker:

so I just want to be very clear that we're talking about VA.gov, not VA.org.

Speaker:

so one of the things I think that's really hard is that with

Speaker:

a, you know, as you said, mission critical application like VA.gov.

Speaker:

this is this is a content You know, a Corpus of content that

Speaker:

is constantly growing, right?

Speaker:

You're going to have more and more information constantly being uploaded.

Speaker:

You also got to potentially archive that information so that people can refer

Speaker:

back to previous versions of content.

Speaker:

So there's never going to be a situation where you're going to reduce the amount

Speaker:

of content that's ever represented in one of these static site builds.

Speaker:

that's, that's a hundred percent true.

Speaker:

We are a government organization.

Speaker:

So we do have laws that government wasn't allowed and not allowed to do.

Speaker:

And archiving content is in there and there's visibility of

Speaker:

content and accessibility laws.

Speaker:

We have to make sure we're following.

Speaker:

So the archive ability is we are every part of that build process I was talking

Speaker:

about is we use S3 bucket version.

Speaker:

So every deploy to S3 is a new version.

Speaker:

So that that whole site is archived there.

Speaker:

Within Drupal.

Speaker:

Nothing's deleted everything's we have an archive state, in our

Speaker:

workflow, but nothing's ever deleted.

Speaker:

So contents always going to grow, right.

Speaker:

We use revisions for everything.

Speaker:

So revisions are just going to be constantly your growing databases.

Speaker:

It's going to be awesome.

Speaker:

I definitely want to talk more about the build pipeline, because I

Speaker:

think there's a lot of interesting things to talk about in there.

Speaker:

But one thing I think is also really interesting and this, you

Speaker:

know, it goes back to obviously the spirit of open source and a Tag1.

Speaker:

And of course you know, the idea of open and publicly available civic technology.

Speaker:

Um, so what I understand is that.

Speaker:

VA.gov is actually completely open source front-end and back-end across the stack.

Speaker:

and I believe that this is available even on GitHub.

Speaker:

can you tell us a little bit about you know, what what's, what's

Speaker:

kind of, well, first of all, what's out there in the open.

Speaker:

Um, how have people been contributing and also what's it

Speaker:

like to be in the open like this?

Speaker:

Yeah, it's actually what drew me to this project in the first place.

Speaker:

I was looking, I wanted to do government work, but so much of it is traditional

Speaker:

behind the, behind the scenes.

Speaker:

You know, nothing's visible and no transparency.

Speaker:

This is an amazing project.

Speaker:

Um, we have a GitHub the department of veteran affairs GitHub page.

Speaker:

And are there are, if you go to that page alone, that org

Speaker:

there's tons of stuff on there.

Speaker:

I mean, for anybody the main repos on there, there's a Vet dash website

Speaker:

and that's the front end build.

Speaker:

There's a VA.gov/cms.

Speaker:

That's the Drupal CMS and there's a VA.gov/team one.

Speaker:

And that's what.

Speaker:

Most teams use to manage their issues.

Speaker:

Um, there's a lot more behind the scenes, a lot more libraries

Speaker:

and lots of that stuff.

Speaker:

But so anybody in the world can go to and spin up the site.

Speaker:

They can, they can, as long as you have access to GitHub, you can clone

Speaker:

the CMS you can, which is Drupal.

Speaker:

You can run.

Speaker:

We have, we use Lando for, with Docker.

Speaker:

So you spin up the Lando instance.

Speaker:

We have a startup script that pulls down a sanitized database,

Speaker:

which is it's all public data.

Speaker:

It's all data.

Speaker:

Just the only thing that sanitizes the user information, right.

Speaker:

Everything else is in there.

Speaker:

So you can go pull that in, spin up a Drupal site spin up that site.

Speaker:

You have the Drupal CMS, the way it is for our editors.

Speaker:

Exactly the same.

Speaker:

same with the front end.

Speaker:

You can spit it out the front end.

Speaker:

you can spin up the vet's API, which is a Ruby back-end all that

Speaker:

you can spin up and any create the whole infrastructure outside.

Speaker:

Of our pipeline.

Speaker:

That's what we do.

Speaker:

So if we have a CI pipeline that spins it up separate, we use the

Speaker:

same scripts everywhere which was really cool to be in the open.

Speaker:

And not only is our code in the open, but our entire process in the open.

Speaker:

So we, on our CMS team repo , um, a CMS repo, but we actually have,

Speaker:

you can go in there now and search for, in we also use ZenHub also to

Speaker:

manage when you ZenHub, it's a plugin for Chrome that manages issues.

Speaker:

It kinda, it kinda gives you a little board within GitHub.

Speaker:

But we use that to mentor epics and ours user stories and tasks, and

Speaker:

all the PRs are public, everything.

Speaker:

So anybody can go in there and do a review.

Speaker:

We've had a couple of people when we were doing, interviewing

Speaker:

for new people to come on.

Speaker:

we actually, some, someone would go in there and do PRs.

Speaker:

So like just before they even got the job.

Speaker:

Right.

Speaker:

So they'd go new PRS.

Speaker:

We ended up hiring one of the guys that did that.

Speaker:

so it's, it's definitely cool to have that out there.

Speaker:

it's a little nervous because you get to be, you get to be a little more

Speaker:

diligent about what you write in your issues and your commits, and you gotta

Speaker:

remember, this is a government, a very serious government organization.

Speaker:

So we use emojis and we smile.

Speaker:

We kind of be, try to be falling as much as we can, but you just still

Speaker:

had to be cognizant of your audience.

Speaker:

Right.

Speaker:

So and I think it's great.

Speaker:

So w you know, all of our, our initiatives are out there and like, so I think

Speaker:

that's kind of important knowing that.

Speaker:

These are American tax dollars.

Speaker:

I'm spending they're paying my salary.

Speaker:

They're just doing all this work to paying for it.

Speaker:

They're paying for all this stuff.

Speaker:

So I think it it's, everyone should know what's going on and we should be

Speaker:

able to get, get to it in my opinion.

Speaker:

So I'm excited.

Speaker:

That's pretty part of the organization, the organization and what we're doing.

Speaker:

So, yep.

Speaker:

Well, I got to say, I really wish that more people had that perspective

Speaker:

of open government, not only in the public sector around the world, but

Speaker:

also in the corporate world as well.

Speaker:

You know, I think we would all benefit from learning from, you

Speaker:

know, all of the work you're doing in the processes that you've set up.

Speaker:

I just took a look myself at the GitHub repository, incredibly well-documented,

Speaker:

you know, incredibly friendly very clear in terms of how things work.

Speaker:

And I want to encourage everybody to go onto, GitHub and visit the department of

Speaker:

veterans affairs organization and check out some of the open repos that are there.

Speaker:

Um, that's really cool.

Speaker:

So we talked a little bit about.

Speaker:

Just to, to, you know, we, we touched on the CI pipeline and I want to

Speaker:

get back to that a little bit later.

Speaker:

And we also talked a little bit about you know, what it's like to be operating

Speaker:

this kind of open government code base.

Speaker:

let's talk a little bit about the you know, the ways in

Speaker:

which your team works together.

Speaker:

Um, I think you know, obviously as you said, millions of people are hitting

Speaker:

this website all the time, and I just wanted to ask you know, just before

Speaker:

we go, go back to the technology a little bit is, you know, what is it

Speaker:

like to be working on the VA.gov team as a content editor, as a technologist?

Speaker:

there's so many teams, there's so many tools, right.

Speaker:

But how has the number of teams interacting with this architecture and

Speaker:

the team size in terms of developers?

Speaker:

How has that impacted the decisions that you've

Speaker:

made?

Speaker:

Yeah, that's a great question.

Speaker:

Well we are very blessed to be open and transparent.

Speaker:

We're still a government organization and it's still the contract.

Speaker:

similar.

Speaker:

So a lot of the we like to say your, sometimes your technology choices are

Speaker:

dependent on contract and the team's ours.

Speaker:

but being part of this overall platform, we kind of call the platform team

Speaker:

within the VA to VA.gov all these different companies is just at least

Speaker:

five or six different contracting companies, very large ones, all work,

Speaker:

all very working there very well.

Speaker:

I don't feel.

Speaker:

The, the isolation between teams, even between like, even with, on

Speaker:

this, on the CMS team, there's two different contracting companies, right?

Speaker:

So that's just, that's more of a government structure the way that works.

Speaker:

it's a lot of complexity as far as who owns different pieces.

Speaker:

Like I talked about before our code pipeline is incredibly

Speaker:

complicated and there's not one team that owns the entire thing.

Speaker:

So there's at least three different teams.

Speaker:

We have CMS team, we have a frontend tools team.

Speaker:

We have a, an ops team, all three of those teams actually contribute in some way.

Speaker:

I said three, what was wrong was actually currently five teams because

Speaker:

we have two different product teams that build products on top of the

Speaker:

platform that and they actually also build on top of the same pipeline.

Speaker:

They had the temp, the HTMLtemplates and stuff like that.

Speaker:

They work on the rescue brokers and create HTML templates.

Speaker:

So there's all these different teams.

Speaker:

And what's been amazing is that we all came together to.

Speaker:

You know, realize the problems we have of, of the build pipeline

Speaker:

speed, how long that takes.

Speaker:

So we're, we're solutioning together, working at the con where we're gonna

Speaker:

fight through the next steps together.

Speaker:

We're going to implement it together.

Speaker:

So while it's, it's, it's definitely complicated and we're having the

Speaker:

different levels of product managers at different levels, even product owners,

Speaker:

there's groups within the VA that own the different products themselves.

Speaker:

So all those different competing priorities come up, but -we'll, you

Speaker:

know, it works out pretty well in the end for the veterans I think.

Speaker:

And I think that's ultimately what you all are doing this for, right.

Speaker:

is for American veterans.

Speaker:

And then for those who have served our country.

Speaker:

And I think it's really easy when we talk about the technology.

Speaker:

When we talk about these build pipelines, it's easy to forget that

Speaker:

there's a human side to all of this.

Speaker:

Not only the people that we have to work with and the people we have to build these

Speaker:

solutions for, but also the end users who are, who are going to be really benefiting

Speaker:

from the applications that we produce.

Speaker:

So, so I want to, so I wanted to ask a little bit about

Speaker:

some of the tech stack here.

Speaker:

We, we, we touched on the backend, we talked, you know, we touched

Speaker:

on the Drupal editorial piece.

Speaker:

We touched on Metalsmith as well.

Speaker:

You know, as you mentioned, it's pulling from multiple sources.

Speaker:

There are these React widgets that are in there.

Speaker:

so let's go back a little bit to the, to the CI pipeline.

Speaker:

I mean you walk this a little bit through the build pipeline.

Speaker:

what are you using in terms of your continuous integration process?

Speaker:

I see that, you know you mentioned for example, that you're using

Speaker:

Jenkins but like what other kinds of tools are in the mix.

Speaker:

And after that, I'd love to hear a little bit about your deployment pipeline

Speaker:

Sure.

Speaker:

So Jenkins is our main, main, our main system or building

Speaker:

orchestration system right now.

Speaker:

we're actually evaluating other solutions, our main ops team, or building

Speaker:

an entirely new stack Docker, all Docker based Kubernetes based on AWS.

Speaker:

so the other tools that we use, we use GitHub actions on the Drupal side, a

Speaker:

lot to run a lot of code quality tests.

Speaker:

we use Circle CI a bit though.

Speaker:

We're honestly kind of moving off of Circle CI to GitHub actions

Speaker:

more that, and that's one of those government contractual things.

Speaker:

I've just, that's the direction from above saying which way to go.

Speaker:

so that's what I'm going to give it an action.

Speaker:

It's just been, it's been great.

Speaker:

It's been a pretty fast for the CMS team itself.

Speaker:

We actually use Tugboat for our ICI.

Speaker:

and Tugboat it's a tool made by Lullabot.

Speaker:

they it's all Docker hundred percent Docker based.

Speaker:

we transitioned onto it recently as in December is when we first

Speaker:

transitioned and it's been an amazing.

Speaker:

Tool to iterate.

Speaker:

well, our CI Pallium before is more traditional one big server.

Speaker:

using Apache it'd be hosts and stuff.

Speaker:

since moving over to Docker and Tugboat, we've been able to upgrade PHP Drush

Speaker:

because we were on Drush 8 for awhile.

Speaker:

just recently last week, actually we got to Drush 10, so exciting.

Speaker:

and all these tools we couldn't upgrade because of our, our previous stack.

Speaker:

We break things now, we're upgrading them very quickly.

Speaker:

So the very exciting stack there, I could talk, I could do a whole

Speaker:

conversation about Tugboat.

Speaker:

yeah, so those are the main tools we use.

Speaker:

Like Jenkins is the, is the main one we have the main system that

Speaker:

we deploy into is called BRD.

Speaker:

It's called build a release and deploy.

Speaker:

the build pipeline is based upon a GitHub commit.

Speaker:

So commit gets created, runs a test suite runs any kind of build that's needed,

Speaker:

creates, creates the artifact and then pushes that to GitHub as a release.

Speaker:

and then those releases might then be deployed by.

Speaker:

deployed job within Jenkins right now.

Speaker:

So, you know, you know, you used to share, you know, I think one of

Speaker:

the things that a lot of people are struggling with right now, which

Speaker:

is when do I make that jump, right?

Speaker:

When do I make that jump from things like Apache and this old way of doing

Speaker:

things over into more containerized architectures, more of the sort of test

Speaker:

driven development, even that, that Tugboat and those sorts of things enable.

Speaker:

so let's, let's talk a little bit about you know, we talked about.

Speaker:

your kind of build pipeline, which is, you know, obviously part of that BRD or BDR.

Speaker:

I always get those letters, BRD.

Speaker:

Um, let's talk a little bit about the deploy pipeline.

Speaker:

cause I think that's a really interesting part of this.

Speaker:

One of the things that I think many people who are listening to this or

Speaker:

watching this might not realize is that when it comes to static sites, there is

Speaker:

both a build step and a deployment step.

Speaker:

And both of those things are incredibly important and are very different

Speaker:

from the previous ways of doing this kind of continuous integration.

Speaker:

so one thing I know about your deploy pipeline is obviously

Speaker:

you're pushing up to S3.

Speaker:

but let's talk a little bit about some of the really exciting things that

Speaker:

you're doing in the deploy pipeline.

Speaker:

you hinted earlier at doing things like link checking.

Speaker:

can you talk a little bit more about what's involved there?

Speaker:

Yeah, absolutely.

Speaker:

So our deploy pipeline before any code goes out with certain checks that,

Speaker:

that occur to make sure that we don't bother like the veterans, like, so this

Speaker:

is all my wrist is all about making sure the veterans get the services.

Speaker:

we have a really complex link checking service that goes through and goes

Speaker:

through every HTML page that was there.

Speaker:

It, it makes sure it runs how everyone's going to conduct a container.

Speaker:

And I'm not sure the details of the top of my head, but it makes sure every link

Speaker:

is real and it has to go to a 404 page.

Speaker:

Um, and that, that kind of 404 page might happen.

Speaker:

If someone publishes a link to a page that's not published yet, or they

Speaker:

publish content, that's not ready to be published many, many times we've

Speaker:

caught content that someone published it, but it wasn't ready to be published.

Speaker:

And it had a link to something else on it.

Speaker:

And that actually stopped the deployed from going out.

Speaker:

So we stopped someone from.

Speaker:

Putting out, pushing out pages that weren't ready to be pushed out yet.

Speaker:

Like when we migrating from some of the health care facilities from their

Speaker:

old sites, which are these team sites to Drupal one time when someone mass

Speaker:

published one of the facilities and it wasn't ready yet, but the link

Speaker:

checker caught that and didn't go out.

Speaker:

So there is a great, great check.

Speaker:

other things that does, like I said before, everything's versions

Speaker:

because they have to be, so it keeps an archive copy of the old site.

Speaker:

all these releases are done.

Speaker:

We use all get, GitHub releases, so you can go to GitHub to the tags

Speaker:

and releases and, and, you know, get all of the content that releases,

Speaker:

which is kind of interesting.

Speaker:

Is it also pushes a a release to composer.

Speaker:

so the vet's website, which is the static site we use composer to pull that into

Speaker:

the Drupal side, to run to our, an ICI test against a mixture we can still build.

Speaker:

So that's kind of an interesting mix of pulling a JavaScript, your website

Speaker:

into a Drupal website, and we use composer to do that cause that way they

Speaker:

tag releases within and it takes you do tags and releases within GitHub.

Speaker:

And then we have dependent by that runs with it, get up to get up service.

Speaker:

If it depended by it does our PR every day, we just merged that PR in

Speaker:

and the next deploy we're updated.

Speaker:

Otherwise we're running tests against old stuff.

Speaker:

And we have some demo sites, RCI pipeline also holds demo sites.

Speaker:

So when, like I talked about those facilities that are moving

Speaker:

from old sites to Drupal, we use Tugboat to stage all the content.

Speaker:

So they'll go on there and otherwise we're publishing content that's old and yeah.

Speaker:

So but that deploy pipeline pushes stuff to static S3 and

Speaker:

then that's basically it, right.

Speaker:

We don't deploy to an Apache server.

Speaker:

We don't have to worry about like, A file system changes this, those

Speaker:

there's no server, you know th that's and that's a really different part.

Speaker:

Like, yes, it's some people they but there's a server in AWS.

Speaker:

Yes, there is.

Speaker:

But from my perspective, there's no server, I just pushed you out S3 object

Speaker:

store and that's it like, and it's super simplified perspective, right?

Speaker:

There's always DNS.

Speaker:

We have load balancers.

Speaker:

And when you go to the VA.gov website, you're not actually going to ADP's

Speaker:

directly, you're hitting some kind of F infrastructure that I'm not even aware

Speaker:

of because it's it's some kind of a file load balancer that gets routed.

Speaker:

It gets routed and started, but eventually just ends up from my

Speaker:

perspective of my user's perspective is like, really I really need servers.

Speaker:

So, which is really cool.

Speaker:

Cool.

Speaker:

And that's so cool.

Speaker:

I mean, you know, I just, just now I loaded VA.gov, you know, hadn't visited

Speaker:

it before it loaded so blazing fast.

Speaker:

I mean, it was so fast.

Speaker:

I had never seen a US government website load this quickly.

Speaker:

in any situation ever, I, including like things like WhiteHouse.gov,

Speaker:

which, which did load.

Speaker:

Pretty quick back in the day.

Speaker:

this is amazing.

Speaker:

I mean, and I think one of the things that's really amazing about this

Speaker:

architecture, Neil and I really do have to commend you and the team for this is that

Speaker:

there is so much underlying complexity and so much under, under the hood activity

Speaker:

going on, as you mentioned, GitHub actions, doing all of these task runs.

Speaker:

also some of the really interesting things around dependency management with

Speaker:

composer and dependent box, but to the end user, it's just that the S3 bucket, it's

Speaker:

just not just store there's literally, it's just a series of static files.

Speaker:

And that I think is, is the beauty of you know, the ways in which we're really

Speaker:

using the static site generators in a way that is extremely alien to how they

Speaker:

were originally used, which is like basic blogs, you know, basic, you know,

Speaker:

static websites into this fully fledged.

Speaker:

application layer, which I think is, is really striking.

Speaker:

so, so we've talked about, we've used the word site and application

Speaker:

kind of interchangeably here.

Speaker:

Right?

Speaker:

And I think there's a sense of, you know, well, okay.

Speaker:

S3 buckets, that's just, that's just the site, you know, it's just assets,

Speaker:

but let's talk a little bit about that interactivity with those React,

Speaker:

widgets, the end user experience.

Speaker:

Now I understand that you you all have a project known as Lighthouse

Speaker:

and just for the, the readership, the viewership, the listenership, this is

Speaker:

not Google's Lighthouse project, but this is the VA's own Lighthouse projects.

Speaker:

Tell us more about this Lighthouse API.

Speaker:

A hundred percent.

Speaker:

So like I talked talk about before the build pallet can pull stuff from

Speaker:

over the place and we have React widgets that pull real-time data.

Speaker:

So the data it pulls, we have a public API that anyone can

Speaker:

access and go create account on.

Speaker:

It's the URL is developer.va.gov.

Speaker:

You can go register an account.

Speaker:

And a little, some of the history behind that URL behind that site,

Speaker:

it was originally set up for people to share their VA medical

Speaker:

information with like Google health and like, those are the other.

Speaker:

So when you set up an account on VA, you can actually link your medical

Speaker:

information to it as a veteran.

Speaker:

it's grown a lot, like, like if you, if you go in there into the

Speaker:

and you kinda, you poke around some of the different areas we have

Speaker:

kind of looking at them myself.

Speaker:

So there's lots of different areas.

Speaker:

So there's benefits information in there and all this is backed by

Speaker:

a kind of engine X load balancer, and we have kind of which uses.

Speaker:

what does it use?

Speaker:

I can't remember the system at the top of my head.

Speaker:

the, the api.va.gov is eventually backed by Ruby.

Speaker:

By a rail system.

Speaker:

and that's, again, it's all public and go access, which I think is also really cool.

Speaker:

The open data OpenGov sort of initiatives.

Speaker:

that's

Speaker:

in there.

Speaker:

Yeah.

Speaker:

And one thing I think that's really interesting about this is

Speaker:

you know, as we see more and more government agencies begin to open

Speaker:

up APIs and developer ecosystems the possibilities are endless, right.

Speaker:

I can just imagine somebody using the Benefits API in Lighthouse or

Speaker:

the Health, API, and Lighthouse to build a chat bot for veterans, right.

Speaker:

or or, or a voice user interface, right.

Speaker:

Especially for veterans who have been injured during you know, due to

Speaker:

some sort of an IDE and they can't look at a screen for too long, they

Speaker:

want to use something that's verbal instead of something that's visual.

Speaker:

it's a really compelling, compelling thing.

Speaker:

I actually want to dig into this.

Speaker:

Amazing and the funniest, the chat, we actually have a chat

Speaker:

bot, projection in the works.

Speaker:

they're working on it right now.

Speaker:

And the chat bot working with -------. not just a connecting real people together,

Speaker:

but also kind of doing some more AI based stuff where tries to answer questions.

Speaker:

based upon the Q and A information.

Speaker:

So there, within the CMS, there's a Q and A set up content type.

Speaker:

We put all information in and reading from that and being able to answer a veteran's

Speaker:

questions based upon that QA information.

Speaker:

So that's something we're working on.

Speaker:

There's a team working on that, where they integrate with our GraphQL

Speaker:

system, again, to build out that that's another other piece of the puzzle.

Speaker:

That's a great idea though.

Speaker:

Yeah.

Speaker:

That's

Speaker:

amazing.

Speaker:

I would love to hear more about that.

Speaker:

you know, I, I, I worked on a team that built out a very similar,

Speaker:

quick question and answer machine for the georgia.gov website.

Speaker:

Okay.

Speaker:

It's actually believe it or not the subject of my upcoming book,

Speaker:

this summer, about voice content.

Speaker:

So it's interesting.

Speaker:

Yeah.

Speaker:

I definitely want to talk more about that.

Speaker:

so, you know, as we know.

Speaker:

You know, and as you've mentioned several times, right?

Speaker:

there's you can't have this kind of amazing architecture that's open

Speaker:

and transparent, but also is doing this amazing orchestration of all

Speaker:

of these different integrations and all of these different environments

Speaker:

without having some challenges.

Speaker:

So I wanted to ask, you know, what are some of the, some of the, you

Speaker:

know, I know you've mentioned some of the plans for improvements coming up.

Speaker:

I know you're looking at Gatsby potentially for evaluation, but what

Speaker:

are some of the kind of other challenges you face with the infrastructure?

Speaker:

like build pipeline problems, GraphQL server problems.

Speaker:

And especially when it comes to, you know, obviously some of the users we

Speaker:

have to serve who are those editors who build the content for, for our veterans.

Speaker:

Yeah.

Speaker:

Thanks.

Speaker:

it, it, there are other trade-offs even though are not up at 2:00 AM,

Speaker:

I still have a server to manage.

Speaker:

I still have expectations of me being up, but being performant.

Speaker:

and we and I, you know, it's not, I say me, it's my team.

Speaker:

We have an amazing team.

Speaker:

That keeps everything running very well.

Speaker:

the GraphQL server.

Speaker:

So I talked a little bit about how we changing the change, our queries around

Speaker:

before, but the load on our Drupal server.

Speaker:

It's, it's, it's a lot.

Speaker:

We, we built pretty often.

Speaker:

So the CI, all the CI pipelines hit our database, the same database

Speaker:

that they use, and that seemed the videos the editors are using.

Speaker:

Right.

Speaker:

So that, that can be a performance problem.

Speaker:

We have, you know, our CPU issues, RDS it's really complicated.

Speaker:

we're actually working a lot, you know, working on mitigating that as

Speaker:

far as like you said, that since we have the separation of the front end

Speaker:

build and we have the content system kind of editorial expectations, right?

Speaker:

So traditional Drupal traditional CMS, you press save, press publish, and it's there.

Speaker:

You don't have that here.

Speaker:

You have to wait for the build pipeline to go out.

Speaker:

You have to wait, it could be an hour, it could be 12 hours until the next

Speaker:

deploy goes out for your content.

Speaker:

Right.

Speaker:

So setting that expectation and communicating that information back to

Speaker:

an editor on that page is very important.

Speaker:

we have things like link checking and, and when you're on a page

Speaker:

is a URL you're on actually live.

Speaker:

So they can kind of look at that.

Speaker:

but again, that's a whole totally different sort of thing.

Speaker:

we have documentation all over the place.

Speaker:

So like I say, lots of different teams, lots of different documentation.

Speaker:

So documentation within the CMS of Read Me documentation, there's, there's diagrams

Speaker:

with different, we have different tools.

Speaker:

We use like mural and whimsical and lucid charts.

Speaker:

And everyone kind of each team kind of uses their own thing once in a while.

Speaker:

And multiple GitHub repository.

Speaker:

So keeping all that information up to date is also a very challenging

Speaker:

because it's, it is constantly changing.

Speaker:

we were agile, so it changes all the time and keeping that up to date for

Speaker:

everybody, especially with the public.

Speaker:

It's important and it takes time.

Speaker:

Absolutely.

Speaker:

So I want to talk just briefly about some of the, and I know that we're

Speaker:

starting to run out of time here, but you know, one of the things I do want

Speaker:

to mention though is you know, obviously this is a unique project, this sort of

Speaker:

you know, when I think back to a lot of the decoupled Drupal architectures

Speaker:

I've worked on, or a lot of the static site generator architectures I've

Speaker:

worked on this is one of those really unique kinds of kinds of architectures.

Speaker:

And so you know, Neil, I think this is a huge accomplishment,

Speaker:

you know, obviously props to both you and the entire VA Tech team.

Speaker:

What are some of the things that you all are most proud of?

Speaker:

and what are some of the things that kind of, you know, get you up in the

Speaker:

morning and, and, you know, get that coffee in your system and get you to work.

Speaker:

Yeah.

Speaker:

So, I mean, it's honestly, it's the people.

Speaker:

everyone across the team or platform team on all of our teams, we're all

Speaker:

service minded, mission focused people.

Speaker:

we understand the veterans and we understand the service we're providing.

Speaker:

We understand how important it is at the end of the day, even with the

Speaker:

arguments and pseudo political stuff.

Speaker:

It, it, we all realize that we, we all can come together on that vision.

Speaker:

Right.

Speaker:

which is great.

Speaker:

it really helps keep me going.

Speaker:

we, our, our team, like I said, we are not only is our project in open

Speaker:

source, we'd be issued an open source.

Speaker:

We do a lot of contributions back to drupal.org.

Speaker:

we sponsor where we can.

Speaker:

We have a lot of several open source projects.

Speaker:

We have a GitHub page department of veteran affairs.

Speaker:

You can look us up.

Speaker:

we've.

Speaker:

We, we continue that way.

Speaker:

we have lots of really great ideas for open-source editorial experience

Speaker:

projects coming in the future that I can't wait to be part of.

Speaker:

Uh, we do speak at DrupalGov cons..

Speaker:

we try to lead the way in, in Drupal government open source , um, and really

Speaker:

we're focused on doing things the right way and necessarily always the easy way.

Speaker:

So w we have really great understanding from top down that doing things

Speaker:

the right way, saves money and time saves the money over time.

Speaker:

So it may be more expensive now, but in a year it's going to be cheaper.

Speaker:

And that's the mindset go back to you know, understanding

Speaker:

we're spending tax dollars.

Speaker:

So that's a mindset we have all the time.

Speaker:

I'm doing things the right way, which is we have that

Speaker:

support top down all the time.

Speaker:

Absolutely.

Speaker:

And, and by the way, just to note for those who are listening here

Speaker:

the VA has a Drupal page that's drupal.org/department-of-veterans-affairs,

Speaker:

department of veterans affairs, separated by hyphens.

Speaker:

Um, amazing, amazing contribution coming from one of the most

Speaker:

important and essential agencies in our, federal government.

Speaker:

Um, and I just love that.

Speaker:

you know, I think that one of the things, especially in this polarized

Speaker:

political environment, I think one of the things that we can all agree

Speaker:

on right, is, is taking care of those who have, you know, made the

Speaker:

ultimate sacrifice for our country.

Speaker:

So , um, next thing I wanted to talk about was the future, you know, I think and

Speaker:

this is where we'll probably end things.

Speaker:

unfortunately though, I imagine the you know, we could probably have a three hour

Speaker:

long conversation about these things.

Speaker:

I'm very interested in, in, like, I really want to dig into a lot

Speaker:

of these pieces more with you.

Speaker:

but like, you know, you, you mentioned some editorial improvements, you

Speaker:

mentioned some interesting stuff coming up on the, on the open-source roadmap.

Speaker:

you know, I know that you're looking at Gatsby what are some of the things

Speaker:

that you're looking at in the future?

Speaker:

What is VA.gov going to look like potentially into three or five years?

Speaker:

That's great questions and we're right in the middle of those planning sessions,

Speaker:

this next quarter of brokering into teams and figuring out like we kind of

Speaker:

have some North star getting principals.

Speaker:

So the main one is we want, by the time one editor presses published, we want

Speaker:

the content to be alive in a minute.

Speaker:

we, we spent some time talking about how hard that's going to be today.

Speaker:

and that that's really, that's the, a main thing, getting that

Speaker:

content live as quick as possible.

Speaker:

so what does that look like?

Speaker:

Is it Gatsby?

Speaker:

Is it, is it still Metalsmith?

Speaker:

Is it a, what does that take?

Speaker:

We don't know that yet.

Speaker:

And that's actually the exciting part for me is I love that solution discovery and

Speaker:

just figuring out what we're going to do.

Speaker:

Um, some cool things.

Speaker:

We have the Drupal side.

Speaker:

We w we did a great amount of research user research last year

Speaker:

for a system we're calling EWA.

Speaker:

So we can't get it off of E walk without the K EWA.

Speaker:

And we call it editor for editorial workflow and assignments.

Speaker:

So building off of Drupal's workspaces, building off Drupal core on the

Speaker:

revision system pre real site real-time previews, revisionable, previews.

Speaker:

and I would like to share a link.

Speaker:

the all it's, all public, all the real user research and designs

Speaker:

you've already put into this And that's coming up this next year.

Speaker:

It's going to be really, really cool, exciting stuff.

Speaker:

I have a pretty big background in, in revisional preview.

Speaker:

I made a system in Drupal seven called site preview system SPS.

Speaker:

I was part of a.

Speaker:

initiative on that.

Speaker:

And that was a lot of, that was a lot of fun, real complex, real great project.

Speaker:

Um, building on top of that building the type of work others have done

Speaker:

you know, standing on the giants of Drupal and just trying to get a little

Speaker:

higher is how we're doing it's it's, it's going to be pretty cool stuff.

Speaker:

Well, Neil, I had no idea that you worked on SPS because I was a user

Speaker:

of site, previous system myself.

Speaker:

So I use some of your code back in the day.

Speaker:

I'm very happy to have done that.

Speaker:

That's amazing.

Speaker:

I hope it did good for you.

Speaker:

I that was that, that was a very fun project for me when I we did that one.

Speaker:

Yeah.

Speaker:

I mean, that was an incredible, you know, I think, I think SPS you

Speaker:

know, for those who don't know much about kind of Drupal history and,

Speaker:

and how, how things were about.

Speaker:

Oh, gosh, five, five or six years ago now.

Speaker:

Seven years ago.

Speaker:

Yeah.

Speaker:

you know, SPS really was revolutionary.

Speaker:

I mean, the fact that you could have this completely comprehensive holistic

Speaker:

preview approach that encompassed your entire site and gave you that complete

Speaker:

peace of mind, it's, it's something that is still rare in the industry.

Speaker:

I don't, I don't think, you know, it's still very rare today, so it's very

Speaker:

difficult and it's a huge achievement.

Speaker:

Well, you know, this is really cool.

Speaker:

I'm excited.

Speaker:

I've got all of these links, open myself, Neil, and we'll obviously

Speaker:

provide all the links as well to our viewing audience, our listening audience.

Speaker:

Um, this has been an incredible conversation.

Speaker:

thank you all so much for hopping on this.

Speaker:

A webinar or podcast today with Tag1 Team Talks.

Speaker:

one thing I did want to say by the way, Neil is I've actually got a

Speaker:

book coming out very soon on Gatsby.

Speaker:

So I'll send you a copy once it's ready to go.

Speaker:

Um, it'll probably be after you've already made your decision, but you know,

Speaker:

maybe at all, it'll, it'll be something that , uh, could add to your shelf,

Speaker:

you know, anyway, thank you so much.

Speaker:

And if you enjoyed this conversation and you want to see more of this, if you want

Speaker:

to bring Neil back to talk about Tugboat QA, if you want to bring Neil back to

Speaker:

talk more about some of these exciting new projects that they're working on

Speaker:

around the White House, APIs at VA.gov remember to upvote subscribe, let us

Speaker:

know how you feel about this webinar.

Speaker:

Share it with your friends and family, with your grandma.

Speaker:

Who's still at home unable to leave because of coronavirus.

Speaker:

Uh, make sure to check out our past talks at tag1.com/tag1teamtalks.

Speaker:

And as always, we'd love to hear your feedback, any suggestions

Speaker:

you have about any topics.

Speaker:

Write to us at tag1teamtalks@tag1.com.

Speaker:

And just want to say once again, thank you so much, Neil.

Speaker:

It was a real pleasure to have you.

Speaker:

It's always a pleasure to hear about some of the amazing things going

Speaker:

on and a thank you also to Michael Meyers and we'll see you next time

Links