Skip to content

workflow.md

Latest commit

 

History

History
85 lines (55 loc) · 3.89 KB

workflow.md

File metadata and controls

85 lines (55 loc) · 3.89 KB

Component & Application Development Workflow

This document lays out general guidelines regarding the development of polymer components and applications based on it in the atom ecosystem.

The objective is to allow for parallel development of applications and the components used by it.

The package manager used is bower since all the development in polymer and atom ecosystem is centered around it. Tags in a git repo are used by bower to represent versions, hence the two terms will be used interchangeably throughout this document. The versions must follow the semver spec, the spec is very informative please ensure that you have read it before continuing with this document.

General Git Workflow

Development of either component or application should adhere to following guidelines.

The guidelines presented here are a simplified version of gitflow.

  1. Master must always contain stable code.
  2. As a result of above requirement every commit on master must be tagged.
  3. Any merges being made into master must be explicit merges even if they are fast forward changes.
  4. A branch named develop should be used to make merges, it contain the latest code which will be released.
  5. There are other branches like release-* or hotfix-* which are used to make releases and bugfixes for that release.

It must be noted that in some cases following such an elaborate workflow may not be effecient, in those cases following rules must be adhered to while making changes.

  1. Master must always contain stable code.
  2. As a result of above requirement every commit on master must be tagged.
  3. Any merges being made into master must be explicit merges even if they are fast forward changes.

Component Dependency Specification

As of now all the components can be categorized into two sets from the perspective of depenedency management.

  1. General components
  2. Specific components

General Components

A lot of elements in the organization atomelements should fall under this category.

Their characteristics can be listed as following.

  1. Independent development and testing.
  2. Don't contain any domain specific logic

Any application using these components is should make use of tilde ranges or caret ranges to specify the dependencies. This method of specification ensures that you can easily update your dependencies.

Specific Components

Almost all the components in the organization travelnxtelements fall under this category.

Their characteristics can be listed as following.

  1. Partly interdependent development and testing.
  2. Contain domain specific logic.

As a result of above characteristics application development may entail changes in these components, also these changes may be best tested along with other components in the application itself.

There is also scope for inter-component tight coupling, which means changes in one component may require changes to be made in another component.

Following rules should be applied while specifying the dependencies in either an application or a component.

  1. By default only mention tilde or caret ranges.
  2. If a non-stable component needs to be tested or consumed while development specify branches instead of ranges.
  3. Once testing is complete update the versions of consumed components and revert back to using tilde or caret ranges.

Miscellaneous Tools and Links

  1. Enforce the gitflow workflow with a tool
  2. A tool for managing multiple git repositories
  3. A video explaining semver.
  4. A handy command in bower for testing components