Front-end-component-library NPM

When You Move

The Front End Component Library for When You Move systems.

What is this repository for?

Shared Components. Text boxes, form fields, buttons etc.

How do I get set up?

Clone the repository locally.
Run npm run build.
Run node server in the ./build folder.
Alternatively to run in dev mode, run npm start in the root folder.

Contribution guidelines

Tests are mandatory on all areas that have functions or logic. Unit/Integration/Acceptance
Code review by someone other than the creator.
Absolutely NO merging, only proper rebasing including squashed commits. Ask if unsure.

Deployment Strategy

We are using our guided pipeline deployment strategy to enable both Continuous Integration (CI) and Continuous Delivery (CD).

The traditional model for this is Unstable -> Stable -> Live.

For projects such as this, there is no web deployment step as this is just an internal nuget package deployment, so the strategy skips Stable.

Branching Model

Very easy, follow these steps for seamless CI.

Do your work in either the sprint branch, or in a feature branch that was created from sprint.
On a regular occurrence (a minimum of once per day), push your work to sprint. This keeps the CI rules.
All pushes to sprint will trigger a build on the build server. Unit tests will run.
Once ready to go to the Unstable environment, follow these steps:

git pull -r                                                                      # Make sure you have the latest

Edit `RELEASE_NOTES.md`;

Adding a new header as per the previous ones.
Making sure points are written in the imperative and succinct as possible.
(you may need to scan back through a git log or similar to identify items since the last release)

#### 1.0.0 - 08.02.2017
* Fix this and that.
* Implement that and the other.
* Resolve the issue with the thingy.

NOTE: At this point you should have one changed file - RELEASE_NOTES.md.

Bump;

NOTE: After running the Bump task below you should have multiple changed files because it will have re-generated the version changes in AssemblyInfo. It is doing this at this point which speeds up the build server builds as it has no need to round-robin for the updates.

Windows:

./build.cmd Bump
git commit -a
git push origin sprint

Nix:

./build.sh Bump
git commit -a
git push origin sprint

Commit message should be in the format of:

Release 1.0.0;

  * Fix this and that.
  * Implement that and the other.
  * Resolve the issue with the thingy.

The build server will now trigger for the Unstable environment. Once this has complete, the gates will be opened to move forward.

Releasing to "Live" environment

git remote update                                                                # This should also fetch down the tag created by the build server.
git checkout master
git pull -r
git rebase v1.0.0
git push

The build server will now trigger for the Live environment. This is built from the tag for assurance. The tests and build are consistent now and we can be assured that if tests are green, we're good to go out.

Configs

We are using NConfig to allow the ability to use per developer configuration. This is really nice in that the server doesn't care how we developers use our development environments! Back of the net!

To override any of the configs, just add a folder called config into the root, and then add a file called Custom.config.

An example would be

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="ApiBaseUrl" value="://localhost:1400" />
  </appSettings>
  <connectionStrings>
    <add name="CommonDataSql" connectionString="Server=.;Database=DbServer;Trusted_Connection=True;" providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

There is of course one exception to this rule... Http projects do not allow files outside of their document root, so for this we need to copy the same file to the root of the Http project. DO NOT INCLUDE THIS FILE IN THE CSPROJ - DOING SO WILL BREAK BUILDS