9 minute reading time; ~1780 words<\/p>\n\n\n\n
Greetings!<\/p>\n\n\n\n
Now that we’ve done our planning, we’re at the part where the rubber meets the road. In this post (and the next few), we’re going to implement the actual cards that we’ve put together.<\/p>\n\n\n\n
Along with walking through how to execute the card, we’re also going to cover the branching and pull request processes, to give you an idea of the mechanics of getting code from our own system into the production codebase.<\/p>\n\n\n\n
While these posts are more technical in nature, I’m going to explain what I’m doing, so that anyone can follow along!<\/p>\n\n\n\n
If you haven’t read the previous posts, I’d suggest you start at An App From Scratch: Part 1 \u2013 What To Build<\/a>. You can also find all the related documents and code here: Building Tailgunner<\/a>.<\/p>\n\n\n\n As a developer, when we start working on a card, we usually break down what we want to do in our head, or on a scrap of paper, or in our notes, but there is some translation of “what the card wants” into “what I need to do”. With that in mind, let’s look at the card to break it down.<\/p>\n\n\n\n Card<\/strong>: US1-C1<\/p>\n\n\n\n Create database tables<\/p>\n<\/div>\n\n\n\n Task<\/p>\n<\/div>\n<\/div>\n\n\n\n Create the database tables required to support creating a template and store their fields.<\/p>\n\n\n\n Acceptance Criteria<\/strong><\/p>\n\n\n\n Details<\/strong><\/p>\n\n\n\n See the tables documented in the technical plan<\/a>.<\/p>\n<\/div>\n\n\n\n First, let’s generate some models. Along with them, we’re also going to add some factories along with our seeders to help generate sample data, and add in the controller for the template, so we have an easy on-ramp to create our API later on.<\/p>\n\n\n\nWhat Do I See?<\/h2>\n\n\n\n
Title<\/h4>\n\n\n\n
Type<\/h4>\n\n\n\n
Description<\/h4>\n\n\n\n
\n
What I Need To Do<\/h3>\n\n\n\n
\n
This task will define the structure of the database tables via code (the migration<\/a>). These migrations will allow us to change what’s in the database automatically, making it reproducible. As well, we’ll define models<\/a>, which are Laravel classes that enable the tool to interact with each table we create.<\/li>\n\n\n\n
In each model, we’ll define any relationships<\/a> with other tables, allowing us to use the query builder more effectively (since it will understand how to connect one table to another).<\/li>\n\n\n\n
We’re going to set up some seeders<\/a> for our tables, so that we have some data for development and testing. These seeders will allow us to repopulate the database tables from scratch whenever we want to.<\/li>\n\n\n\n
Now that we have defined tables and seeders, we’re going to execute them, so the tables are created and populated.<\/li>\n\n\n\n
With the table creation completed, the last thing to do is have a look at the tables themselves. This is a quality check to make sure that the structure is what I expect, and what makes sense for the data and purpose. If anything doesn’t feel right, this is our chance to adjust the migrations and try again.<\/li>\n<\/ul>\n\n\n\nPutting It Into Action<\/h2>\n\n\n\n
Create new migrations and models for tables<\/h4>\n\n\n\n