Skip to content
Jarkko Moilanen edited this page Jul 17, 2014 · 20 revisions

This page describes the process how new features are added to production state services. The below is theoretical description of the process which is good if you are presenting this in a conference or for "dummies". But if you are a developer and need understand the real process, see section "Github Feature workflow" at the end of this page.

https://github.com/koulutuksenpilvivayla/pilvivayla-development/blob/master/images/adding-new-feature2.png?raw=true

Lisää kuvaan "cleanup code and document it" ennen githubiin vientiä.

Feature story card

Is based on information provided at kysy.pilvivayla.fi service by any of the users. They start a new request at the kysy.pilvivayla.fi service by selecting category "Ominaisuus". This process is descibed in details in another page.

Tests are written

We use tests driven development methodology. Tests first, then code. All tests are written with XXXXX tools. That part of the process is described in here[LINK].

Implementation

After tests have been created, it's time to implement feature in code.

Tests executed

All the tests are executed during the night and test results are published at [ADDRESS HERE]

If success, code is added to public Github repository. If failure, refactoring and tests again until we have success (given that tests are valid).

Code added to production

In the final phase, code is added to given production state service. This is done manually by pulling the changes from github and resrtarting service. In the future this should be automated with release management service some sort of.

Github Feature workflow

We use feature workflow for development (All in command line)

  1. Clone repository git clone <git url> for example git clone [email protected]:koulutuksenpilvivayla/pilvivayla-api-manager.git (Note! If you used our Vagrant scripts, you already have the code cloned in your environment.)
  2. Go inside the repository folder
  3. Get devel branch git checkout --track origin/devel
  • git prints: Branch devel set up to track remote branch devel from origin. Switched to a new branch 'devel'
  1. Start a feature branch: git checkout -b my-new-cool-feature devel
  2. Develop, add files, make commits
  • Add the files for commit, for example git add -A (add all changed files)
  • Then write a note about what your commit is about, for example git commit -m "Translated a few lines"
  1. Push the feature to central repo: git push -u origin my-new-cool-feature
  • git push works now for extra commits for the feature if needs fixing
  1. Make pull request in Github to propose new feature
  • CI(Jenkins) triggers tests against devel branch TBD
  • Jenkins informs the lead and feature developer about success/failure, email? TBD
  1. Team discussion about the new feature
  2. Changes and code cleanup if needed
  • git push the code cleanup
  • Lead developer accepts the pull request and merges the feature manually to devel
  1. Merging devel to master is done daily by Jenkins if devel branch passes tests.