Growth Phase Summary

[00:00:00]
>> Erik Reinert: Let's talk about the phase changes really quickly from this second phase. So we went through startup, we experienced what startup was like, and you got to experience the pains of managing infrastructure on your own. That was super fun, right? And then in phase two, you kind of got to understand the pains of CI and like how to set all that up and like build this developer experience, right?

[00:00:21]
And basically through that, we added database migrations so database databases can be securely and safely updated. Now we added a make file for developer automation, which also means that we added automation for CI too. We added a multi stage docker file for different uses. Again, that was the real takeaway I wanted you to have.

[00:00:41]
There is you can make a build image that you can reuse in CI, but then if you want to just have a very smaller production image, you can separate those two and reuse them as much as you want. We added a build step for code changes. We added a test step for schema changes, and then we added a deploy step for automated deployments, right?

[00:00:59]
Then the biggest part too is we added a lot of future support because we have GitHub Actions in there now. Because we have a Makefile in there now. We can add more commands in the future, we can add more pipeline jobs in the future. This is that growth that I'm telling you about.

[00:01:15]
It's not just growing, but we want to make sure it can continue growing. But what are the pros to this phase, this growth phase? Well, there was no real impactful changes made if you think about it, right? Like we never touched the service once, service never went down, right?

[00:01:31]
And we still got tons of value out of what we did, right? It was behind the scenes, but it was still a lot of added value, right? We improved our schema management, right? We improved developer productivity, we improved code reliability as well as the life cycle with delivery jobs.

[00:01:50]
Now we have a complete life cycle. Merge, merge, deploy. Merge, deploy, right? Test, merge, deploy, test, merge, deploy. That's the whole. If I was in some way to sum up, really a big part of this course, that's what you just want to get comfortable with, is what are the steps you need to do to get to your goal?

[00:02:08]
I want to build, I want to test, I want to deploy, okay? In the future now I want to build, then I want to run migrations, then I want to test. We built an actual life cycle there that we can rely on. What are the cons to this?

[00:02:23]
Well, we still have no infrastructure management whatsoever. If we have to go back and manage the service, it's still clunky. We still have to deal with App Runner a bit. We don't have a staging environment, so we're deploying directly to production right now. There's no I want to check in dev and then go to prod.

[00:02:44]
There's also no network isolation. So again, your database is publicly exposed as well as if you had a dev environment, that would be publicly exposed too. There's no service support really here either. What happens in the future if we want to build another application? How would those two communicate?

[00:03:03]
And how would we be able to build more of a microservice infrastructure? We can't really do that in this current setup, because it's just like App Runner. Those are the cons, basically.