Full Stack Basics for the Non-Developer, Part 1
Let's visualize and talk about the "full stack" of web development. From a developer's standpoint, we're probably talking about the layers of code involved in delivering a website to an end user. But let's back up further for a moment and just talk about a stack of things. Given all the different device, language, and application options out there, many stacks of things in this case! There's the stacks involved for phone application development, stacks for websites, stacks for console gaming, and more! To avoid head explosions to the extent possible possible, I'm going to focus on Metal Toad's most common stack.
I'm hungry, so I'm making my stack a bit bigger than just code layers. What I'll attempt to illustrate and explain is the most important layers involved between a web developer and a website visitor, both on their computers. I'll touch on people, software, hardware, languages, concepts, and more in order to provide a fairly holistic view. Much of this stuff (at least on the surface level) isn't as complex as the terminology and acronyms may make it sound. Realize that there are hundreds of intermingled components that this doesn't touch on; if you want the overview, read start to finish, or if you want to get more in-depth, start clicking the links to Wikipedia and beyond. Feel free to call me on any technicalities or suggest changes/additions in the comments! There's a lot of info to cover, so I'm going to break it down into three posts, with this being part 1. If you prefer, you can read the long-form post with all the content in one.
1 - Developer
A developer gets to sit down (or stand up) in front of their desk and build a website. Pretty straightforward here, but note that while some level of knowledge of the full stack is necessary for development, true full stack developers that can write and deliver code from top to bottom at a senior level are rare. Many have a focus in one of three areas (which we'll touch on further below): frontend development, backend development, or devops. A developer will spend much of their time learning, writing code, configuring applications, testing their work, and deploying what they've written.
2 - Local Environment
A local evironment (AKA (i) "localhost" in networking, AKA "local machine") is just a developer's device (laptops in Metal Toad's case). We configure them to develop, test, and deploy websites (AKA "development environment"). These machines are set up with all of the applications installed that make up part of the website's stack so that a developer can write code, deploy it on their own machine, and pull it up in their browser to test and review before committing their work to a repository. Some technologies involved are:
- (a) A code editor is a tool that supports the creation of source code. Since source code is plain text, it can be as simple as a basic text editing program, but many modern editors include tools like syntax highlighting, autocomplete, and formatting to significantly speed development. A current favorite for many of Metal Toad's developers is Sublime Text.
- (b) A command line interface (CLI) in conjunction with a command line interpreter (AKA "shell") is used to run system-level commands via text inputs, as opposed to a graphical user interface (GUI) like OS X and Windows. On Mac computers with OS X (Metal Toad's primary development devices), the bundled application to interact with the operating system via command line interface is Terminal. It's actually an emulator (AKA "imitator") of a command line interface within the OS X GUI. That's not confusing at all. Anyway, OS X is a Unix-based operating system, which means that developers are interacting with the operating system in Terminal using the most common Unix shell, Bash, with Unix commands. But wait, there are shells for more than just operating systems. Programming languages also have shells...
- (c) We use a tool called Capistrano to automate and manage (ii) deployments from local machines to other remote machines. Capistrano is Ruby language-based, so developers interact with it via a Ruby shell in Terminal. If you've heard a developer discuss "cap prod deploy" they're talking about invoking deployment to a production server via the command line.
3 - Repository
A repository is simply a storage location. When the term is used in relation to websites, it generally refers to the organization and storage location for the website's source code files. For most dynamic websites, there are three main components involved: (vi) Code, Database, and Assets.
- Code - Source code is all of the programming language and markup language-based documents and configuration files used to render a website.
- Database - The database is used to store content, settings, user information, and other dynamic elements that interact with/are requested by the source code.
- Assets - In addition to the source code files, websites are comprised of media elements including images and self-hosted videos, as well as PDFs and other types of resources.
A complex website is comprised of hundreds if not thousands of source code files. Managing them all can be confusing and tedious on a one person project; add in multiple developers working on the same code base and a code management system is crucial. This is where (vii) version control comes in. Just like you may be used to creating and managing multiple copies of a draft design PSD or working in Google Drive with multiple collaborators and revisions, version control allows for creation of a revision history and multiple-user collaboration on a shared repository. For version control and repository management, we use (d) Github, which is based on Git. Github is a web-based Git repository hosting service that provides a GUI interface for repository management and source control in addition to command line use.
When it comes to version control and Git specifically, there are a number of terms that you've likely heard mentioned that warrant basic definition:
- Checkout - When a developer starts work on a project with an existing repository, they use the git checkout command and choose which branch (defined below, and generally the "master" branch, or primary branch for the project) they'd like to "check out" and download to create a local copy of the repository.
- (iii) Commit - Much like you would save changes as you go with restore points or copies to revert back to, using the git commit command allows a developer to take a snapshot of their repository and any changes since their last commit as you work. It also requires a comment with the commit explaining the nature of the changes, which will help others debug and determine what changes were made. Developers are encouraged to commit regularly with useful comments for context!
- (iv) Push - Once a developer has gotten to a good stopping point or a point where their local copy of the repository has updates ready to be shared, the git push command allows them to "push" their commits to Github, where other developers can then see the changes.
- (v) Pull - As developers work, they'll want to periodically update their local repository with the changes made by other developers on the project. To do this, they use git pull, which "pulls" the changes down to update their local repository.
- Branch - Branching using git branch allows a developer to work on a version of the repository that is separate from the master. There are several reasons that a developer may want to do this, but often it's for work that requires parralel development on the same repository that shouldn't be rolled out at the same time. A perfect example of this is a new featureset that may take several months to develop for an existing live site. Developers could create a branch for these new features, while maintaining the master branch to be ready for deployment at any time if bugs come up that need quick resolution on the live site.
- Merge - After a developer has completed work in a branch and wants to combine their work with the master branch, they use git merge to merge the branch back into the master. At this point, there's the chance that one or more files have had the same lines of code changed in both master and the branch, and the lines of code don't match. These is called an edit collision, the most common type of merge conflict. Git provides a useful toolset to help developers resolve merge conflicts by determining which code should take precedence.
- Fork - To fork is essentially the same as to branch, the main difference being that when a developer forks a code base, they do so with the intention of not merging the code in the future, and instead often moves forward with the intent of creating a separate piece of software.
With developers regularly committing and pushing changes in a repository, one more important piece of the puzzle is developers giving each other feedback on their work. This is where (e) code review comes into play. For code review we use Barkeep, a system that integrates with Git to allow for seamless peer review and feedback on code while in development.