Understanding 19 Commonly-Used, Key Terms

Development Glossary for Project Managers, Business Analysts, Project Owners, Junior Developers, and Non-Technical Persons

Being a non-technical person or just being new in the programming space can be challenging when you’re just starting a new project and you have to get up to speed quickly.

Questions like these might come to mind:

– A request to pull what?
– Failing pipeline? You’ve got leaks?
– You’ve pushed your commit? I’ve already told other people about our sprint commitment…

There are a lot of new terms that you might encounter, and knowing what they mean can help you in your day-to-day interactions. The following examples apply to web app-related situations, but the definitions apply across the board..

Understanding these key terms can help you understand, for instance, why something is taking a long time to complete, why someone has a problem and in what part of the process a problem is encountered.

1. Automation Tests
2. Build
3. Build Number
4. Code Cut
5. Code Freeze
6. Code Repository
7. Code Review
8. Code Revert
9. Commit
10. Deployment
11. Environment
12. Feature Branch
13. Feature Branch Testing
14. Pipeline
15. Pull Request / PR
16. Pushing Code
17. Refactoring
18. Unit Tests
19. VM / Virtual Machine

1. Automation Tests

These are like little robots. If your team is doing web development, automation tests are basically code written for getting the website tested automatically.

People working in the testing field (QA engineers, SDETs) are writing pieces of software that can open a browser and do all the actions that a real user can do, such as logging in, clicking a button, scrolling, etc. They use programming languages to write these automation tests.

Automation tests can be run each night to test if the application is working fine. Also, they can be run whenever a developer wants to introduce new code in the application, so that everyone can sleep well knowing that if that code is causing something to break, they would be notified as fast as possible.

2. Build

A build is basically a package with all the code written by developers, packaged in a way that makes it faster to run.

For example, developers normally use white spaces in their code and they have dozens of folders and files where they divide their code so that it can be easier to comprehend. When the code has to be run as a website, all those white spaces, or that file divinization, are not required.

Builds are created knowing that the spaces will be removed. The code is stuck together in just a few files that get compressed, so that they will have a smaller file weight.

3. Build Number

Whenever code is merged, some pipelines are run and a new build is created. That build is going to have a number assigned to it. It’s like a ticket that you get when waiting in a line. The number helps other people (usually from DevOps) to know what code to promote to higher environments or directly to production.

These release numbers are usually introduced in a Release Notes document, which is used for informing the DevOps team what build numbers should be deployed to higher environments.

4. Code Cut

A code cut occurs when the code present in a testing environment is going to be moved manually to a higher environment, such as to production.

5. Code Freeze

A code freeze is the moment in which no other code merges are allowed, even if there are pull requests marked as approved. This is established and announced so that the code cut process can be taken without having anything to interfere.

6. Code Repository

A code repository is like a folder stored on the internet (something like a Google Drive) where the code is going to be held so that any developer working on a project can download it and start working.

The code from this repository can be merged or not. Think about having a folder called “Project.” In this folder, there can be two sub-folders, “Merged Code” and “Not Merged — Stored Only.”

“Not Merged — Stored Only”: If it is not merged, it means that the code is just stored online and the developers can see it, but they don’t need to download it to start working on a new feature.

Merged code is code that every developer needs to have on their local machine as a starting point for writing new code. Also, this merged code can be present on the staging/testing site, so that the QA team can test it.

7. Code Review

This is every developer’s nightmare. Whenever a developer has finished writing their code, along with the unit tests, they need to have some other developer (usually a team leader or a lead engineer) look over their code to see if it is correct, well-written, bug-free, and so on.

If everything is fine the code can be approved, but if any changes are proposed, the developer who initially wrote the code has to make some changes. When they finish doing the changes they have to re-test that code and then they have to ask for another code review.

This review is done as part of the pull request (abbreviated as “PR”).

8. Code Revert

A code revert is like taking back something that you gave to your friend. All the code of a project is held in a code repository, and whenever a new feature is introduced, that code repository will have the code for it present in its files. If a developer introduced some code that is not working fine he will have to remove the code from that code repository.

This process is not exactly like going and deleting some files. The developer has to remove code probably from multiple places and he has to ensure that he only removed what was required and that the application is working as before when he finishes deleting stuff.

9. Commit

“I’ve made a commit” or “I’ve pushed my commits” — it is probable that you’ll hear these statements pretty often.

A commit is just a version of the code. Think about working on a word document, where you save it multiple times:

Document Version 1–12 april.docx
Document Version 2–13 april.docx
Document V3–14 April.docx
Document Final.docx
Document Final Final.docx

This is the same document, just in different stages of execution. Developers do something similar when writing code, but they use a special tool for that and these versions are called “commits.” Pushing these commits is like saying “I’ve uploaded my code to that code repository,” but it’s not yet merged.

10. Deployment

Deployment is the process of getting code turned into a live website. After the build is created from the code, it has to be deployed (a.k.a. transferred on a server) so that it can be accessed as an interactive website. Without this deployment step, you would just have a bunch of code that can be run on your computer, but it wouldn’t be accessible by anyone else.

11. Environment

When developers write code, they initially test that code “locally,” which is a way of saying that they are running the website just on their computer. Whatever changes they make to the code, they can see that change only on their computer.

That’s called a local environment. An environment is, therefore, the place where the code is run.

We first have the local environment, and we can have something called a Dev environment, a QA environment or a Staging environment. Depending on the structure of the project that you are working on with your team, these names can be different and you can have two or more environments.

A Dev/QA/Staging environment is pretty much like the live website, but it’s not actually it. Users are not going to ever use that website. It is for testing purposes so that any change that developers make can be fully tested before getting those features in production, where users can see it.

There are projects that have multiple environments, like:

  • Local
  • Dev
  • QA
  • E2E
  • Pre-Prod
  • Production

There are websites that can have three environments:

  • Local
  • Staging / QA
  • Production

Or there are websites that can have just two environments:

  • Local
  • Production

All these environments have different purposes and they are set up based on the project requirements. A staging environment for a website may be different from the staging environment of another website.

12. Feature Branch

A feature branch is like putting in a new window. In order to change the window, you need to have that window created, so you would need to take some measurements first in order to make sure it’s the correct size. Then you would have to place it into the wall and test that it closes and opens well.

If everything is fine with the window, you’d take down the plastic wrap and then you can brag to your friends.

Normally, a feature branch is like that window. Usually, developers take the code of the application on their local machines (this is pretty much the same as taking the measurements for the window) and they start working on a certain feature (creating the window). Since they are making changes just on their machines, anything that they do isn’t going to impact the work of anyone else or the production website.

Once the feature is coded and tested, it goes into the testing environments (placing the window on the wall and testing it) and then in production (removing the plastic wrap and bragging to the friends).

13. Feature Branch Testing

This stage of testing is when a person specialized in application testing (QA engineer, SDET) copies that feature branch on their computer and tests that the new feature is working as desired.

This is different from testing on a live website or from testing on a Staging/QA environment because the tester can’t directly go to an address like google.com and check the website. That person has to do some initial setup so that the project can be run on their computer.

14. Pipeline

Similar to automation tests, pipelines are like little robots that check the code that has been introduced (merged) by a developer. When a developer receives the approval to merge their code, they actually merge it and these robots will start to play. They check that the code is valid and without vulnerabilities, that there are no errors in the code, that the application won’t break if this code is introduced, and so on.

These pipelines can work smoothly and, if they are successful, the code is promoted to a higher environment (to QA/Staging, for example). If they are broken (and they can break often), the pipeline has to either be restarted, or the Dev, the DevOps, or the SDETs have to check why it failed.

A pipeline can take anywhere from a few minutes to more than an hour until it is completed.

15. Pull Request (PR)

A pull request is like the moment when you give your paper to your teacher so that they can exam it. The teacher then gives you a grade for that paper.

The difference here is that the paper is just the developer code changes and the teacher(who is, in this case, a team lead, a lead engineer, a senior developer, or any developer with code review rights) is going to tell you what you did wrong or what you can improve on.

When you make the changes, the reviewer checks your code again. Once it’s all complete you can merge your code.

16. Pushing Code

This is the process of transferring the code from one place to another. It can be moved from a developer’s local machine to the internet (in the code repository) or the code can be pushed from one environment to another.

17. Refactoring

Refactoring of the code is the process in which code is going to be rewritten, but the functionality will be kept in place. It’s like rewriting a sentence using different words, but keeping the same idea. While the words are different, you convey the same message to the reader.

18. Unit Tests

Unit tests are pieces of code written to test code. For example, a developer may write a piece of code that adds two numbers.

For that code, they usually have to write another piece of code that will certify that the adding functionality is really adding numbers correctly.

Unit tests are written to assure that a program is going to work correctly. With these unit tests, a developer knows that his code works fine even without opening the website in the browser. This also ensures that if a developer comes later to the code and changes something by mistake(he can for example change the adding to a subtraction), he’ll be notified by the unit tests that that is wrong.

19. Virtual Machine (VM)

A virtual machine is like a computer, but it doesn’t have a physical form. For example, you have an operating system on your computer (ex: Windows) and, on top of that, you have different programs.

Your computer can have software on it that can give you access to another computer that is not owned by anyone. That “computer” is just a program. So, from your device that is, for example, a Macbook with the Catalina OS on it, you can get access to another computer that has Windows as the operating system.

Refer to this article whenever you need a refresher on the meaning of these key terms.

Background Image