Skip to content

Instantly share code, notes, and snippets.

@hungryzi
Last active May 9, 2017 18:10
Show Gist options
  • Save hungryzi/977bfb48ad0816ba3f1b502df87bb48c to your computer and use it in GitHub Desktop.
Save hungryzi/977bfb48ad0816ba3f1b502df87bb48c to your computer and use it in GitHub Desktop.
Engineers onboarding

Day 1: Scrum

We use Scrum methodology to manage our projects (with some modifications). Our Scrum board is on Trello.

Our sprints are usually 2 weeks.

Reading: http://blog.trello.com/beginners-guide-scrum-and-agile-project-management

Video: https://www.youtube.com/watch?v=XU0llRltyFM

Day 2: Git flow

We use Git flow. (bản tiếng Việt)

Branch master is for production, and develop is for staging. We DON'T commit directly to these branches and only create Pull Requests to them. Code needs to be reviewed by other engineers before merging.

Please install git flow in your machines.

Our setup:

  • Branch name for production releases: master
  • Branch name for "next release" development: develop
  • Feature branches prefix: feature/
  • Bugfix branches prefix: bugfix/
  • Release branches prefix: release/
  • Hotfix branches prefix: hotfix/
  • Support branches prefix: support/
  • Version tag prefix: (nothing)
  • Hooks and filters directory: ./.git/hooks

Day 3: Automated Testing and Continuous Integration

We want to be confident that our applications work correctly and we want to deploy often. Therefore, it is crucial that we have automated tests and only deploy code that has been tested.

There are different types of tests:

  • Unit tests test the smallest unit of functionality, typically a method/function (e.g. given a class with a particular state, calling x method on the class should cause y to happen).
  • Integration tests build on unit tests by combining the units of code and testing that the resulting combination functions correctly.
  • End-to-end tests involves performing tests on the full system (e.g. using your web page via a web browser) to see whether the application's functionality satisfies the specification.

We use a combination of these tests to ensure the correctness of our systems. The combination should look like a pyramid in the end, with Unit tests be the base (the most number of tests) and End-to-end tests at the top (the least number of tests).

test pyramid

Read more on why Google thinks that this pyramid makes sense.

For Ruby/Rails

These are main libraries that we use for our tests in Ruby. This list should be updated if anything changes.

For Unit/Integration tests

  • RSpec to write tests.
  • Rspec-mocks to mock/stub parts of system that are not under tests.

End-to-end tests

Helpers

For JavaScript

TODO

For iOS

TODO

For Android

TODO

Note Besides automated tests, we also have QA for certain parts where it is necessary.

Continous Integration & Continuous Deployment.

Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each commit is then verified by an automated build (running of all tests), which alerts teams about any problem in the code early.

In our process, each commit on any branch will trigger a build automatically. When a pull request is merged to develop, and the build passes, the code will be deployed to staging server automatically. This practice is called Continuous Deployment. For production, however, we don't deploy automatically since the risks are higher.

This practices only work if we can be confident that when our tests pass, our applications run correctly. Thus we need to write good and fast tests.

We will be using Jenkins for our CI (Zi's setting it up).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment