Dev setup

This documents purpose is to help developers get up and running at NoA Ignite.

Feel free to comment, reach out on Slack or IRL, if there’s questions, anything missing or unclear.

Table of Content

1. Applications & Software
   1.1 Brew
   1.2 Visual Studio Code
   1.3 Nvm, Node & Yarn
   1.4 Terminal
   1.5 Teams, Slack & Outlook
   
2. Git, GitHub & ZenHub
3. Schedule & Time Reporting
4. Links & Resources

Applications & Software

Brew

When installing new software we recommend using Brew.

Homebrew is a free and open-source software package management system that simplifies the installation of software on Apple’s operating system, macOS. The name is intended to suggest the idea of building software on the Mac depending on the user’s taste.

Visual Studio Code

The recommended code editor is Visual Studio Code. Here follows extensions that are required or recommended.

A perfect installation of vs-code extensions is a beauty that can not be described by words ☺️ #Adam Söderström.

Nvm, Node & Yarn

Below are some of the main package management software we use. For a more explicit guide of the installation process check out this blog post. But preferably use brew when installing Nvm.

Nvm

Node version manager (NVM) is a version manager for node.js. Nvm is used to switch between different verisons of node since different projects might use different versions.

brew install nvm

Node

Node.js is an open-source, cross-platform JavaScript runtime environment. Use Nvm when installing Node to be able to mange the versions.

nvm install node

If you want to load a specific version, use subcommand. With this subcommand, you can load Node.js by version number or —lts flag.

nvm use <version>

To see what node version you are currently using.

node -v

Yarn

Yarn is an other package manager we use.

npm install --global yarn

Terminal

The terminal is a developers best friend #Alexander Flink.

Some tips to make the terminal more pleasurable to work with and to get some dev respect from your colleagues:

1. Use a “smart” terminal.
2. Style the terminal.
3. Install terminal packages.

External Terminal

You can use whatever terminal you like but our current recommendation is to use Warp.

Styling

You can style your terminal inorder to make it look more aesthetically pleasing. This can be done by manually styling the terminal or by using packages such as oh-my-zsh.

If you want to style your internal terminal in Visual Studio Code you can follow this guide.

Terminal Packages

Some usefull terminal packages you can use are.

• Z
• Git Friendly
• Fast-syntax-highlighting
• Zsh-auto-suggestions

Installing z was one of the best moments of my life #Martin Barri

Teams, Slack & Outlook

Teams, Slack & Outlook should already be installed on your computer if not click the links.

Git, GitHub & ZenHub

Git

Before working with git you should have access to all of our 3 GitHub organizations.

• NoA Ignite
• Oakwood
• Making Waves

Below is an instruction of how we work with git in our projects. There might be some differences in the git worklflow between projects but the ambition is that the workflow should be the same accross all projects.

Everything below this heading is my interpretation of Git Flow. Please look at Git Flow for one-source-of-truth. If you found don’t agree with my interpretation, feel free to reach out! ☺️ #Adam Söderström

Branches you’ll get familiar with when working in a project:

• master/main
• develop
• stage
• feature/* - always branches from develop
• release/* - always branches from develop
• hotfix/* - always branches from master

* = Issue number

How these branches are being used in various projects may differ, but they shouldn’t. Please check, if possible, with a developer that is/has been involved in the project before, if there’s any questions or confusion.

The naming convention of these branches are base upon Git Flow. Feel free to use the git-flow-tool.

master/main

The master/main branch is intended to always represent what is currently in production / “is live”. You should never work directly in this branch. For critical bugs or similar, use hotfix branches. Look in the Git Flow for more info.

stage

The stage branch is intended to always represent what is currently in the stage / QA environment. When a feature (or perhaps a hotfix) branch is ready to be tested, you merge that branch into stage. If you receive feedback upon the feature / hotfix, make changes in the feature/hotfix branch and merge it back in to stage.

You should never work directly in the stage branch.

ZenHub

ZenHub is a Agile project management tool that works within GitHub. It’s currently used in all the Next.js projects.

It provides the functionality to manage tickets / issues in more detail than GitHub’s project boards.

To make it work, you’ll have to install their browser extension

GitHub Issues

Every task, there has to be an ticket / issue, which describes what changes that should occur.

Every issue create comes with an automatically generated ticket number, see image below (“acast-app #490”):

The changes regarding the issue should be attached through commits inside a feature branch.

Creating a feature branch for the issue above, is made by:

• Creating a new branch from the branch develop, named feature/490 (based on the image above)

Schedule & Time Reporting

Time reporting and scheduling is done and retrieved in Workbook.

Please reach out to your PM or management regarding access and how-to’s.

A great note-taking tool for time reporting is Toggl Track.

Links & Resources

Below are some useful links and resources to tools & software that we use at NoA Ignite.