-
Notifications
You must be signed in to change notification settings - Fork 1
Adding new feature
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.
Lisää kuvaan "cleanup code and document it" ennen githubiin vientiä.
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.
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].
After tests have been created, it's time to implement feature in code.
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).
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.
We use feature workflow for development (All in command line)
- Clone repository
git clone <git url>
for examplegit clone [email protected]:koulutuksenpilvivayla/pilvivayla-api-manager.git
(Note! If you used our Vagrant scripts, you already have the code cloned in your environment.) - Go inside the repository folder
- 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'
- Start a feature branch:
git checkout -b my-new-cool-feature devel
- 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"
- 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
- 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
- Team discussion about the new feature
- Changes and code cleanup if needed
-
git push
the code cleanup - Lead developer accepts the pull request and merges the feature manually to devel
- Merging devel to master is done daily by Jenkins if devel branch passes tests.