Software Development Lifecycle

Software Development Lifecycle

The software development lifecycle is a structured process that guides the creation of software.

Source Control

Source Control allows developers to maintain a history of the codebase by tracking changes while facilitating collaboration. In VS Code you can see your commit history in source control under the graph tab.

It will also show other people’s commits and who made them if you’re working together with others.

When you click on the commit it will show you what changes you made and what files they were in.

Forking

Forking creates a personal copy of a repository which allows developers to work independently without affecting the main project

This is my fork of platformer_4x. With a fork you can contribute to the main repository by clicking contribute and making a pull request. You can also sync the fork to match the main repository.

Branching

Branching allows for isolated development of features or fixes within a single repository. This allows multiple people to be able to collaborate on the same repository.

Here is an example of branches me and my group had when working on platformer_4x. My own branch is local but everyone else’s is usually a remote branch.

Merging

Merging integrates changes from one branch into another, typically from a feature branch into the main branch.

Techniques for merging include:

Standard merge
Squash and merge
Rebase and merge

Here’s a past merge I did with my own branch with the main branch

This is what it looks like in source control. I had done a merge in order to sync my branch and its changes with the main branch.

Pull Requests

Pull requests are a method for proposing and reviewing code changes before integration into the main codebase. They can be used to facilitate code review and discussion between team members.

Here is an example of what part of a pull request looks like. This one is already completed.

You can look at the commits and which files there are changes to.

The typical way we had done pull requests was just through the contribute feature of our forks. If you click contribute you can start a pull request and it will contain all the commits on your fork and compare all the changes that are different from the main repository. Then you make the pull request and it has to be approved before becoming a apart of the main repository. Pull requests can be denied or its possible that you might run into a pull request that flags as having merge conflicts at some point.

Building

Building or build process is typically associated with compiled languages where code is “compiled” to create executable or deployable artifacts. The term can also be used more broadly with interpreted languages to refer to the steps involved in writing, testing, and deploying the code even though there is no explicit compilation involved.

Testing and Verification

Testing and verification is conducted to ensure that software is built according to specifications and meets requirements. The goal is to catch issues early, thus reducing the costs and effort required to fix bugs later in the development process.

Automated testing can be incorporated to verify individual components with units test or check how different parts work together with integration tests.
Verification can occur through code reviews and design walkthroughs, and inspection of software artifacts.

I had been testing my changes by running a make and looking at the localhost version made from what I have on VS Code and seeing if that works properly. Then I’ll commit usually only when it works properly.

Deployment

Deployment involves moving tested and approved code to production environments. Continuous Deployment can be employed to automate the process and provide frequent releases. Best practices for deployment include:

Leveraging automated deployment processes
Pre-staging environments
Incorporate monitoring and rollback capabilities

You can see deployment in Github Actions This is from the Github action of my most recent commit.