├── .github └── workflows │ └── slack-notification.yml ├── Readme.md ├── assets ├── DVELP-org-chart.png ├── GCP_keyfile.gif ├── ISO27001.pdf ├── d-for-dvelp.png ├── dvelp-logo.png ├── greenhouse_assign_coordinator.gif ├── greenhouse_filter.gif ├── greenhouse_schedule_interview.gif ├── greenhouse_submit_scorecard.gif ├── live-code-share-1.png ├── live-code-share-2.png ├── live-code-share-3.png ├── personal-goals.png ├── product-cadence.png ├── product-offer-evaluation.png ├── product-org-structure.png ├── review-schedule.png ├── risk-impact.png ├── roles-and-resp.png └── supplier-policy.png ├── careers ├── README.md └── jobs │ ├── fullstack-node-engineer.md │ ├── product-manager.md │ └── senior-fullstack-node-engineer.md ├── guides ├── Airline-Roadmap.md ├── acronyms.md ├── code-management │ ├── Readme.md │ ├── git-shopify.md │ └── git.md ├── code-style │ ├── Readme.md │ ├── config │ │ ├── .jshint.yml │ │ ├── .rubocop.yml │ │ ├── .scss-lint.yml │ │ ├── .slim-lint.yml │ │ └── lints.rake │ ├── frontend-libraries.md │ ├── frontend-setup.md │ ├── frontend-standards.md │ ├── owasp-checklist.md │ └── templates │ │ ├── Readme.md │ │ ├── models.md │ │ ├── services.md │ │ └── specs │ │ ├── Readme.md │ │ ├── controllers.md │ │ ├── features.md │ │ ├── helpers.md │ │ ├── mailers.md │ │ ├── models.md │ │ ├── requests.md │ │ ├── services.md │ │ └── views.md ├── dialogflow │ ├── agents-management.md │ └── ruby-client-for-dialogflow-api.md ├── environments │ ├── Readme.md │ ├── circle-ci-2.md │ ├── deploying-shopify.md │ ├── diagnostics.md │ └── heroku-pipeline.md ├── marketing │ └── social-media-policy.md ├── project-process │ ├── Readme.md │ ├── bug-classifications.md │ ├── commercial-terms.md │ ├── continuous-improvement-support-and-hosting.md │ ├── design-guidelines.md │ ├── go-live-checklist.md │ ├── harvest-forecast.md │ ├── roles-and-responsibilities.md │ ├── running-a-demo.md │ ├── scrum-process.md │ └── trello.md ├── ruby-gems │ ├── Creating Ruby Gems bespoke for DVELP.md │ ├── README.md │ ├── gemfury.md │ └── installing-private-gems.md ├── tools │ ├── README.md │ ├── live-code-share.md │ ├── ngrok.md │ ├── s3-bucket.md │ └── zoiper-soft-phone.md └── twilio │ ├── number-porting.md │ └── twilio-number-porting-timeline.png ├── handbook ├── README.md ├── best-practice │ ├── anti-corruption.md │ ├── anti-harassment.md │ ├── health-and-safety-policy.md │ └── whistle-blowing-policy.md ├── hr │ ├── absence.md │ ├── compassionate-leave.md │ ├── disciplinary-procedure.md │ ├── dress-code.md │ ├── equal-opportunities.md │ ├── expenses-policy.md │ ├── grievance-procedure.md │ ├── maternity-policy.md │ ├── off-boarding.md │ ├── on-boarding.md │ ├── org-chart.md │ ├── paternity-policy.md │ ├── personal-details.md │ ├── redundancy-policy.md │ ├── referral-programme.md │ └── retirement-policy.md ├── information-security │ ├── README.md │ ├── acceptable-use.md │ ├── access-control.md │ ├── anti-virus-malware-policy.md │ ├── asset-management.md │ ├── backup-recovery-policy.md │ ├── business-continuity.md │ ├── classification-of-information.md │ ├── cryptographic-controls-policy.md │ ├── data-protection-policy.md │ ├── database-limits.md │ ├── incident-response.md │ ├── information-transfer-policy.md │ ├── internal-security-audit.md │ ├── isms-meetings.md │ ├── people-security.md │ ├── physical-and-environmental-security.md │ ├── risk-management.md │ ├── special-interest-groups.md │ ├── statement-of-applicability.md │ ├── supplier-policy.md │ └── vulnerability-management.md ├── operations │ ├── docusign.md │ ├── greenhouse.md │ ├── hubspot.md │ ├── interviewing.md │ ├── invoicing.md │ └── slack.md ├── professional-development │ ├── developer-proficiency.md │ ├── external-training-courses.md │ ├── goal-reviews.md │ ├── mentoring.md │ └── smart-goals.md └── quick-reference.md ├── managing-our-time.md ├── product-org ├── README.md ├── contributing │ └── README.md ├── interfaces │ └── README.md ├── key-event-calendar.md ├── partner-solutions │ └── README.md ├── product │ ├── README.md │ ├── lifecycle.md │ ├── products.md │ └── release-phases.md └── roles │ ├── README.md │ ├── lead-product-engineer.md │ ├── product-designer.md │ ├── product-engineer.md │ ├── product-marketing-manager.md │ └── product-owner.md └── scripts ├── README.md ├── git_heroku_add.sh ├── git_merge_pull_request.sh ├── heroku_sync_config.sh ├── heroku_sync_db_to_local.sh ├── shopify ├── .gitignore ├── circle.yml ├── config.yml └── gruntfile.js └── tmux-session-switch.sh /.github/workflows/slack-notification.yml: -------------------------------------------------------------------------------- 1 | name: slack-notification 2 | 3 | on: 4 | pull_request: 5 | types: [closed] 6 | 7 | jobs: 8 | slack-notification-with-optional-parameters: 9 | runs-on: ubuntu-latest 10 | name: Sends a message to Slack when a pull request is closed 11 | steps: 12 | - name: Send message to Slack API 13 | uses: archive/github-actions-slack@v1.0.0 14 | with: 15 | slack-bot-user-oauth-access-token: ${{ secrets.SLACK_BOT_USER_OAUTH_ACCESS_TOKEN }} 16 | slack-channel: general 17 | slack-text: "We have just updated the cookbook. Have a look at the changes here: ${{ github.event.pull_request._links.html.href }}" 18 | slack-optional-icon_emoji: ":fire:" 19 | - name: Result from "Send Message" 20 | run: echo "The result was ${{ steps.notify.outputs.slack-result }}" 21 | -------------------------------------------------------------------------------- /assets/DVELP-org-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/DVELP-org-chart.png -------------------------------------------------------------------------------- /assets/GCP_keyfile.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/GCP_keyfile.gif -------------------------------------------------------------------------------- /assets/ISO27001.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/ISO27001.pdf -------------------------------------------------------------------------------- /assets/d-for-dvelp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/d-for-dvelp.png -------------------------------------------------------------------------------- /assets/dvelp-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/dvelp-logo.png -------------------------------------------------------------------------------- /assets/greenhouse_assign_coordinator.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/greenhouse_assign_coordinator.gif -------------------------------------------------------------------------------- /assets/greenhouse_filter.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/greenhouse_filter.gif -------------------------------------------------------------------------------- /assets/greenhouse_schedule_interview.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/greenhouse_schedule_interview.gif -------------------------------------------------------------------------------- /assets/greenhouse_submit_scorecard.gif: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/greenhouse_submit_scorecard.gif -------------------------------------------------------------------------------- /assets/live-code-share-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/live-code-share-1.png -------------------------------------------------------------------------------- /assets/live-code-share-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/live-code-share-2.png -------------------------------------------------------------------------------- /assets/live-code-share-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/live-code-share-3.png -------------------------------------------------------------------------------- /assets/personal-goals.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/personal-goals.png -------------------------------------------------------------------------------- /assets/product-cadence.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/product-cadence.png -------------------------------------------------------------------------------- /assets/product-offer-evaluation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/product-offer-evaluation.png -------------------------------------------------------------------------------- /assets/product-org-structure.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/product-org-structure.png -------------------------------------------------------------------------------- /assets/review-schedule.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/review-schedule.png -------------------------------------------------------------------------------- /assets/risk-impact.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/risk-impact.png -------------------------------------------------------------------------------- /assets/roles-and-resp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/roles-and-resp.png -------------------------------------------------------------------------------- /assets/supplier-policy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/assets/supplier-policy.png -------------------------------------------------------------------------------- /guides/Airline-Roadmap.md: -------------------------------------------------------------------------------- 1 | # The Airline Roadmap Structure 2 | 3 | This section of the Cookbook defines our process for creating the roadmap for Airline. 4 | 5 | ## The Overall Goal of Airline 6 | 7 | **Help our customers design, build and manage customer service automation at scale.** 8 | 9 | This goal should be referred to throughout the roadmap process to make sure we prioritise and build the right features. 10 | 11 | ## How is the Airline Roadmap Defined 12 | 13 | Goals are set on a quarterly basis by the Airline Product Manager based on the overall Airline Goal and discussion with the team. 14 | 15 | Anyone in the company can suggest epics they think should be added to the Airline Roadmap on this [Trello board](https://trello.com/b/e1fAwJCw/airline-roadmap). 16 | 17 | Once a month a group of people from across the business will review these epics and decide which should be added to the roadmap (and therefore the In Planning list) and what their priority is. Based on this, in depth planning sessions will be organised for each new epic added to the In Planning list. After each of these the roadmap will be updated by the Airline Product Manager. 18 | 19 | We will give regular updates on the roadmap during monthly meetings and if you want to know what's going on day to day, you can refer to the [Airline Trello Board.](https://trello.com/b/ynXz49sl/airline-2020) 20 | 21 | ## Roles and Responsibilities 22 | 23 | | Role | Team Member | Responsibilities | 24 | |-----------------|-------------------|-----------------------------------------------------------------------------------------------------------------------| 25 | | Product Manager | Annise Makki | Ensuring that Product Roadmap is defined based on key objectives and stakeholders input. | 26 | | Tech Lead | Ilya Lozer | Technical delivery of the project
Ensure excellence in code quality
Make sure DVELP technical standards are met | 27 | | Scrum Master | Rotates regularly | Ensure scrum ceremonies occur and board hygiene is up to date. 28 | -------------------------------------------------------------------------------- /guides/code-management/Readme.md: -------------------------------------------------------------------------------- 1 | # Code Management 2 | 3 | Code is at the centre of all of our work. Keeping it clean and tidy is 4 | fundamental to an efficient, manageable and sustainable process. 5 | 6 | The following are guides to how we wrangle 100s of repositories: 7 | 8 | * [Git](git.md) 9 | * [Git For Shopify](git-shopify.md) 10 | 11 | -------------------------------------------------------------------------------- /guides/code-management/git-shopify.md: -------------------------------------------------------------------------------- 1 | # Git && Shopify 2 | 3 | Our quick guide to working collaboratively with Git, GitHub and Shopify projects. 4 | 5 | ## Create a Feature 6 | 7 | Create a `staging` branch from `master`. 8 | 9 | ``` 10 | git checkout master 11 | git pull 12 | git checkout -b staging 13 | ``` 14 | If the staging branch already exists, rebase it on-top of master: 15 | 16 | ``` 17 | git checkout staging 18 | git rebase master 19 | ``` 20 | 21 | Finally, push the staging branch to remote so we have a communal copy: 22 | ``` 23 | git push origin staging 24 | ``` 25 | 26 | ## Production hotfix 27 | 28 | If you need to make a hotfix on production, create a new, local branch off `master`. 29 | 30 | ``` 31 | git checkout master 32 | git pull 33 | git checkout -b hotfix-some-bug 34 | ``` 35 | 36 | Once you have fixed the bug, or added the small feature, create a new Pull Request to `master`. 37 | 38 | For more information about writing good commits and creating Pull Requests, check-out our [guide to Git](https://github.com/DVELP/cookbook/blob/master/guides/Git.md). 39 | 40 | ## Merge staging with master 41 | 42 | Once the featured is complete and all Pull Requests to staging have been merged, rebase `staging` on top of `master`, give it a final review and once your are happy, merge it in. 43 | 44 | ``` 45 | git checkout master 46 | git pull 47 | git checkout staging 48 | git rebase -i master 49 | git checkout master 50 | git merge --ff-only staging 51 | git push origin master 52 | ``` 53 | 54 | ## Deploy to production 55 | 56 | It's extremely important that we aim to mirror the master branch with the production code at all times, so once your new feature is on master, make sure you deploy it to production. 57 | -------------------------------------------------------------------------------- /guides/code-style/Readme.md: -------------------------------------------------------------------------------- 1 | # Code Style 2 | 3 | At DVELP we value our code quality. These style guides help to keep our code 4 | consistent and looking beautiful. The guides are derived from practices and 5 | conventions generally accepted and used by the wider community. 6 | 7 | ## Getting Started 8 | 9 | We understand that no two projects are the same, each one a little different to 10 | the next. With that in mind, we recommend using these guides as starting point. 11 | They can be tweaked and moulded on a per project basis, but make sure everyone 12 | on the team is comfortable with any adjustments you make. 13 | 14 | ## Linting 15 | 16 | We use a number of tools to enforce style compliance: 17 | 18 | * JSHint for Javascript lints 19 | * Rubocop for Ruby lints 20 | * SCSS Lint, for SCSS lints 21 | * Slim Lint, well, for Slim lints 22 | 23 | First, you need to add the gems to your project's Gemfile: 24 | 25 | ```ruby 26 | group :development, :test do 27 | gem 'jshint', require: false 28 | gem 'rubocop', require: false 29 | gem 'scss_lint', require: false 30 | gem 'slim_lint', require: false 31 | end 32 | ``` 33 | 34 | ### Configs 35 | 36 | Then you need to add some configs that implement our styles. 37 | 38 | The following is a list of configuration files you're encouraged to use in a new 39 | project: 40 | 41 | * [JSHint](config/.jshint.yml) 42 | * [Rubocop](config/.rubocop.yml) 43 | * [SCSS Lint](config/.scss-lint.yml) 44 | * [Slim Lint](config/.slim-lint.yml) 45 | 46 | These files should go into your project's root directory. 47 | 48 | You should run the lints as a part of your build. To add lints to the default 49 | task you can use the following rake file. Just put it into `lib/tasks` 50 | directory. 51 | 52 | * [lints.rake](config/lints.rake) 53 | 54 | ## Templates 55 | 56 | The following are a collection of templates that will act as a reference point 57 | for some of the commonly used patterns and approaches throughout our codebases. 58 | 59 | The aim of the templates is to help improve consistency of approach not just 60 | within individual codebases, but across the entire portfolio. 61 | 62 | These templates are not designed to be hard and fast rules, or fully functional 63 | models, rather to act as a common starting point. 64 | 65 | * [Models](templates/models.md) 66 | * [Services](templates/services.md) 67 | * [Specs](templates/specs) 68 | 69 | ## Security 70 | 71 | * On every change we need to check every relevant to the changes points from 72 | this list: [OWASP Web Application Security Testing Checklist](owasp-checklist.md). 73 | -------------------------------------------------------------------------------- /guides/code-style/config/.jshint.yml: -------------------------------------------------------------------------------- 1 | files: ['**/*.js'] 2 | exclude_paths: ['vendor/assets/javascripts'] 3 | options: 4 | asi: false 5 | bitwise: true 6 | browser: true 7 | camelcase: true 8 | curly: true 9 | forin: true 10 | immed: true 11 | latedef: nofunc 12 | maxlen: 80 13 | newcap: true 14 | noarg: true 15 | noempty: true 16 | nonew: true 17 | predef: [ 18 | '$', 19 | 'jQuery', 20 | 'jasmine', 21 | 'beforeEach', 22 | 'describe', 23 | 'expect', 24 | 'it', 25 | 'angular', 26 | 'inject', 27 | 'module' 28 | ] 29 | quotmark: true 30 | trailing: true 31 | undef: true 32 | unused: true 33 | -------------------------------------------------------------------------------- /guides/code-style/config/.rubocop.yml: -------------------------------------------------------------------------------- 1 | AllCops: 2 | DisplayCopNames: true 3 | Exclude: 4 | - 'db/schema.rb' 5 | - 'bin/*' 6 | - 'vendor/*' 7 | - './Rakefile' 8 | 9 | Lint/Debugger: 10 | Enabled: true 11 | 12 | Metrics/LineLength: 13 | Max: 80 14 | 15 | Metrics/MethodLength: 16 | Max: 12 17 | 18 | Naming/MethodName: 19 | EnforcedStyle: snake_case 20 | 21 | Naming/VariableName: 22 | EnforcedStyle: snake_case 23 | 24 | Rails: 25 | Enabled: true 26 | 27 | Style/AlignParameters: 28 | EnforcedStyle: with_fixed_indentation 29 | 30 | Style/BlockComments: 31 | Exclude: 32 | - 'spec/spec_helper.rb' 33 | 34 | Style/Documentation: 35 | Enabled: false 36 | 37 | Style/FirstParameterIndentation: 38 | EnforcedStyle: consistent 39 | 40 | Style/GuardClause: 41 | Enabled: true 42 | 43 | Style/HashSyntax: 44 | Exclude: 45 | - 'lib/tasks/*.rake' 46 | 47 | Style/IndentArray: 48 | EnforcedStyle: consistent 49 | 50 | Style/IfUnlessModifier: 51 | Enabled: false 52 | 53 | Style/MultilineMethodCallIndentation: 54 | EnforcedStyle: indented 55 | 56 | Style/PercentLiteralDelimiters: 57 | PreferredDelimiters: 58 | '%': () 59 | '%i': '[]' 60 | '%q': () 61 | '%Q': () 62 | '%r': '{}' 63 | '%s': () 64 | '%w': '[]' 65 | '%W': '[]' 66 | '%x': () 67 | 68 | Style/StringLiterals: 69 | EnforcedStyle: single_quotes 70 | 71 | 72 | 73 | 74 | -------------------------------------------------------------------------------- /guides/code-style/config/.slim-lint.yml: -------------------------------------------------------------------------------- 1 | skip_frontmatter: false 2 | 3 | linters: 4 | CommentControlStatement: 5 | enabled: true 6 | 7 | ConsecutiveControlStatements: 8 | enabled: true 9 | max_consecutive: 2 10 | 11 | EmptyControlStatement: 12 | enabled: true 13 | 14 | RedundantDiv: 15 | enabled: true 16 | 17 | LineLength: 18 | enabled: true 19 | max: 80 20 | 21 | RuboCop: 22 | enabled: true 23 | 24 | TagCase: 25 | enabled: true 26 | 27 | TrailingWhitespace: 28 | enabled: true 29 | -------------------------------------------------------------------------------- /guides/code-style/config/lints.rake: -------------------------------------------------------------------------------- 1 | require 'rubocop/rake_task' 2 | require 'slim_lint/rake_task' 3 | 4 | task :jshint_custom do 5 | puts 'Running JS lints...' 6 | Rake::Task['jshint:lint'].invoke('.jshint.yml') 7 | end 8 | task default: :jshint_custom 9 | 10 | RuboCop::RakeTask.new 11 | task default: :rubocop 12 | 13 | task :scss_lint do 14 | puts 'Running SCSS lints...' 15 | if system('bundle exec scss-lint') 16 | puts "\e[32mAll good!\e[0m" 17 | else 18 | exit 1 19 | end 20 | end 21 | task default: :scss_lint 22 | 23 | SlimLint::RakeTask.new do |t| 24 | t.config = '.slim-lint.yml' 25 | end 26 | task default: :slim_lint 27 | -------------------------------------------------------------------------------- /guides/code-style/frontend-libraries.md: -------------------------------------------------------------------------------- 1 | # Using front-end libraries 2 | 3 | Using Bower to manage javascript components. 4 | 5 | Install Bower: 6 | 7 | ``` 8 | npm install -g bower 9 | ``` 10 | 11 | You can use `bower init` to create new `bower.json` file. 12 | 13 | Now we can install packages with `bower install --save` 14 | 15 | ``` 16 | bower install jquery --save 17 | ``` 18 | 19 | Use files only that you need while using Bower-installer 20 | 21 | Install `bower installer` globally 22 | 23 | ``` 24 | npm install -g bower-installer 25 | ``` 26 | 27 | Specify the path in `bower.json` you would like to use 28 | 29 | ``` 30 | "install": { 31 | "path": { 32 | "css": "assets/stylesheets/vendor", 33 | "scss": "assets/stylesheets/vendor", 34 | "js": "assets/javascripts/vendor" 35 | } 36 | } 37 | ``` 38 | 39 | #### Ignore files 40 | 41 | Files can be ignored and not copied. For example, some libraries can have dependencies that we don't want to use so we can ignore them. 42 | 43 | ``` 44 | "ignore": [ 45 | "fastclick", 46 | "jquery-placeholder" 47 | ], 48 | ``` 49 | 50 | #### Overriding main files 51 | 52 | A lot of registered components for bower do not include bower.json configuration. Therefore, bower does not know about any "main files" and therefore, by default bower-installer doesn't know about them either. Bower-installer can override an existing main file path or provide a non-existant one: 53 | 54 | ``` 55 | "install": { 56 | "sources": { 57 | "lazysizes": [ 58 | "bower_components/lazysizes/plugins/bgset/ls.bgset.js", 59 | "bower_components/lazysizes/plugins/respimg/ls.respimg.js", 60 | "bower_components/lazysizes/plugins/respimg/ls.parent-fit.js", 61 | "bower_components/lazysizes/lazysizes.js" 62 | ], 63 | } 64 | } 65 | ``` 66 | 67 | #### Rename files 68 | 69 | Files can be renamed when bower-installer copies them to their new destination. 70 | 71 | ``` 72 | "install": { 73 | "sources": { 74 | "slick-carousel": { 75 | "mapping": [ 76 | { 77 | "bower_components/slick-carousel/slick/slick.js": "slick.js" 78 | }, 79 | { 80 | "bower_components/slick-carousel/slick/slick.scss": "_slick.scss" 81 | } 82 | ] 83 | }, 84 | } 85 | } 86 | ``` 87 | -------------------------------------------------------------------------------- /guides/code-style/frontend-setup.md: -------------------------------------------------------------------------------- 1 | # Front-end strategy 2 | 3 | ### What we use 4 | 5 | #### Foundation 6 framework 6 | 7 | Use only required components and libraries. We don't need to use normalize with Foundation 6, it included in foundation-global-styles mixin. 8 | 9 | #### Grunt 10 | 11 | Use grunt tasks for creating svg sprites. You can use `grunt` command to run grunt tasks. 12 | 13 | #### Autoprefixer 14 | 15 | Use Autoprefixer gem or Autoprefixer of [grunt-postcss](https://github.com/nDmitry/grunt-postcss) task in Shopify projects. 16 | 17 | #### Bower 18 | 19 | Use bower with bower installer to manage libraries and control their versions. [Using front-end libraries](https://github.com/DVELP/cookbook/blob/front-end-strategy/guides/Using%20front-end%20libraries.md) 20 | 21 | #### Front-man 22 | 23 | [Front-man](https://github.com/DVELP/front_man) is a gem that includes utilities classes, z-index variables and helpers for sprite and image tags. 24 | 25 | #### Frequently used plugins 26 | 27 | * [Lazysizes](https://github.com/aFarkas/lazysizes) is a lazyloader for images, background images. Use only the necessary components. Usually the additional components are: 28 | * ls.bgset.js - for responsive background images, 29 | * ls.respimg.js - for cross browser responsive image support, 30 | * lazysizes.js - main file 31 | * [Slick](https://github.com/kenwheeler/slick) is a plugin for sliders, carousels. 32 | * [Magnific Popup](https://github.com/dimsemenov/Magnific-Popup) is a responsive jQuery Lightbox plugin. 33 | 34 | #### Development and page optimization 35 | 36 | * Mobile-First development method - it is more efficient and future-friendly. 37 | * Svg files for sprites should be cleaned. Without extra tags like , , which can cause problems in IE browser, icons can't be displayed at all. If we need to change the colour of icons they should be cleaned of fill attributes or stroke, depending on the type of icon. 38 | * Use svg sprites. 39 | * Optimize Images. All images (.jpg, .png) should be optimized. They can be saved for web via Photoshop at least or optimized using specialized services/tools. 40 | * Put JS files at the bottom of page. 41 | * Minimize HTTP Requests. JS and CSS files should be combined into a single file and minimised. 42 | * Avoid fixing layout with javascript. If you can, try to use only css styles and avoid js. 43 | * Trying to reduce the number of DOM Elements. 44 | 45 | #### Page speed testing 46 | 47 | Page speed can be checked in DevTools in Chrome browser on Network tab. There you can find information about the amount of requests, speed of DOMContentLoad and page load. 48 | [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/) - service that analyzes the page speed and recommends how it can be improved for both the desktop and mobile versions of a site. 49 | [GTmetrix](https://gtmetrix.com/) - tool which measures the speed of the site and gives recommendations for improvements. 50 | 51 | ###### What we can improve 52 | 53 | * Use ESLint - tool that analyses javascript code and points out potential problem areas, bad coding styles. Create a common settings for the team in .eslintrc file and use it in your IDE at least and follow its instructions. 54 | * Rethink some of the front-man components. We can remove _pollyfills.scss file if we use Autoprefixer and remove some classes from _utility.scss file that are used rarely. 55 | -------------------------------------------------------------------------------- /guides/code-style/templates/Readme.md: -------------------------------------------------------------------------------- 1 | # Templates 2 | 3 | The following are a collection of templates that will act as a reference point 4 | for some of the commonly used patterns and approaches throughout our codebases. 5 | 6 | The aim of the templates is to help improve consistency of approach not just 7 | within individual codebases, but across the entire portfolio. 8 | 9 | These templates are not designed to be hard and fast rules, or fully functional 10 | models, rather to act as a common starting point. 11 | 12 | * [Models](models.md) 13 | * [Services](services.md) 14 | * [Specs](specs) 15 | 16 | -------------------------------------------------------------------------------- /guides/code-style/templates/models.md: -------------------------------------------------------------------------------- 1 | # Models 2 | 3 | The following is a base template for an ActiveRecord model `Customer`. 4 | 5 | ## Key Points 6 | 7 | * Avoid AR callbacks where possible, prefer [service](services.md) lead 8 | architecture 9 | 10 | * Order associations, scopes and validations alphabetically 11 | 12 | * Aim to remove business logic that is not directly related to reading from or 13 | writing to the database 14 | 15 | ## Template 16 | 17 | ```ruby 18 | class Customer < ActiveRecord::Base 19 | # Inclusions and extensions 20 | include Module 21 | 22 | # Public custom attributes 23 | attr_accessor :trigger_activation_mailer 24 | 25 | # Constants 26 | DEFAULT_COUNTRY = 'Poland'.freeze 27 | 28 | # Associations 29 | belongs_to :company 30 | has_many :orders 31 | has_one :address 32 | 33 | # Validations 34 | validates :first_name, presence: true 35 | validates :last_name, presence: true 36 | 37 | # Callbacks, in lifecycle, then alphabetical order (if you really have to) 38 | before_validation :parse_name 39 | after_create :send_email 40 | 41 | # Scopes 42 | scope :is_active, -> { where(active: true) } 43 | 44 | # Nested attributes 45 | accepts_nested_attributes_for :orders 46 | 47 | # Delegate methods 48 | delegate :post_code, to: :address 49 | 50 | # Gems methods calls 51 | enumerize :title, in: %i[mr ms] 52 | mount_uploader :avatar, AvatarUploader 53 | 54 | # Class methods 55 | def self.activate 56 | find_each do |customer| 57 | customer.update_attributes(active: true) 58 | end 59 | end 60 | 61 | # Instance methods 62 | def age 63 | calculate_age(dob: dob) 64 | end 65 | 66 | # Protected methods 67 | protected 68 | 69 | def parse_name 70 | # some logic 71 | end 72 | 73 | # Private methods 74 | private 75 | 76 | def send_email 77 | # we shouldn't send emails from AR models 78 | end 79 | 80 | def calculate_age(dob:) 81 | # some calculation 82 | end 83 | end 84 | ``` 85 | -------------------------------------------------------------------------------- /guides/code-style/templates/services.md: -------------------------------------------------------------------------------- 1 | # Services 2 | 3 | As our applications grow in size we often find our ActiveRecord objects 4 | getting increasingly bloated, containing more and more business logic that doesn't really belong. We have already committed to skinny controllers, so we turn to services for help. 5 | 6 | The following is a collection of services that will help manage the lifecycle of 7 | an `Order` object. 8 | 9 | ## Key Points 10 | 11 | * Put services in the `app/services/` directory 12 | 13 | * Don't call services services e.g. `order_service.rb`. It's in the services 14 | directory, we know it's a service 15 | 16 | * When creating services for ActiveRecord objects, create folders with the 17 | plural form of the name e.g. `app/services/orders/` 18 | 19 | ## Template 20 | 21 | ```ruby 22 | # app/services/orders/creator.rb 23 | module Orders 24 | class Creator 25 | def initialize(params: {}) 26 | self.params = params 27 | end 28 | 29 | def create 30 | order = Order.new(params) 31 | if order.save 32 | take_payment(order) 33 | send_email(order) 34 | end 35 | 36 | order 37 | end 38 | 39 | private 40 | 41 | attr_accessor :params 42 | 43 | def take_payment(order) 44 | Payments::Creator.new(order: order).create 45 | end 46 | 47 | def send_email(order) 48 | OrderMailer.confirmation(order).deliver_now 49 | end 50 | end 51 | end 52 | 53 | # app/services/orders/updater.rb 54 | module Orders 55 | class Updator 56 | def initialize(order:, params: {}) 57 | self.order = order 58 | self.params = params 59 | end 60 | 61 | def update 62 | result = order.update_attributes(params) 63 | 64 | if order.cancelled? 65 | process_refund 66 | send_cancellation_email 67 | end 68 | 69 | result 70 | end 71 | 72 | private 73 | 74 | attr_accessor :order, :params 75 | 76 | def process_refund 77 | end 78 | 79 | def send_cancellation_email 80 | OrderMailer.cancellation(order).deliver_now 81 | end 82 | end 83 | end 84 | ``` 85 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/Readme.md: -------------------------------------------------------------------------------- 1 | # Specs 2 | 3 | Specs (we use [RSpec](http://rspec.info)) are crucial to building scalable applications. They not only help verify the implementation of our code and how new features interact with it, but also provide clear guidelines to our future selves about the expected behaviour of an application. 4 | 5 | Clearly defined and well implemented specs will help us refactor with ease and 6 | ship with confidence. 7 | 8 | ## Rspec and Rails 9 | 10 | Rails applications typically have the following groupings of specs: 11 | 12 | ### Unit 13 | 14 | Unit tests cover lower-level functionality of individual classes or methods. 15 | 16 | * [Controllers](controllers.md) 17 | * [Helpers](helpers.md) 18 | * [Models](models.md) 19 | * [Mailers](mailers.md) 20 | * [Services](services.md) 21 | * [Views](views.md) 22 | 23 | ### Integration 24 | 25 | Integration tests are behavioural driven and in most cases will replicate the 26 | expected experience from a 'first user' perspective. They help to decouple 27 | behaviour from implementation, allowing for easier refactoring, and will ensure 28 | that the individual components (units) of an application work well together. 29 | 30 | * [Features](features.md) 31 | * [Requests](requests.md) 32 | 33 | ## Recommendations 34 | 35 | The following are key recommendations that will help to keep your specs 36 | manageable and more enjoyable to code with as your application grows in size. 37 | 38 | ### Test in Four Phases 39 | 40 | We typically try to structure each individual test into four phases: 41 | 42 | * setup 43 | * exercise 44 | * verify 45 | * teardown (most often handled by the test suite) 46 | 47 | The overarching goal is to improve readability and consistency. By testing in 48 | four phases, you should have everything you need to understand the logic 49 | contained within the test. 50 | 51 | A worked example is as follows: 52 | 53 | ```ruby 54 | it 'sets a uuid for the customer' do 55 | # setup 56 | attrs = FactoryGirl.attributes_for(:customer) 57 | customer = Customer.new(attrs) 58 | 59 | # excercise 60 | customer.save 61 | 62 | # verify 63 | expect(customer.uuid).to_not be_nil 64 | end 65 | ``` 66 | 67 | ### Focus On Behaviour, Not Implementation 68 | 69 | By focusing on the behaviour of your individual methods, or features, your test suite becomes much more robust and will offer two key advantages: 70 | 71 | * Tests are less brittle as they are decoupled from implementation 72 | * Refactoring is quicker and you will have a greater level of confidence the 73 | expected behaviour of the app has not changed 74 | 75 | ### Use let With Great Caution 76 | 77 | * [Let's Talk About This](https://dvelp.co.uk/articles/lets-talk-about-this) 78 | * [Let's Not](https://robots.thoughtbot.com/lets-not) 79 | * [My Issues With Let](https://robots.thoughtbot.com/my-issues-with-let) 80 | 81 | ## References 82 | 83 | There are many, many articles and theories about how and what to test. The 84 | templates above are a very high-level examples of how we would approach our 85 | test-suite, but I highly recommend a read of the following: 86 | 87 | * [Better Specs](http://www.betterspecs.org/) 88 | * [The Illusion of TDD](http://dncrht.github.io/2017/03/17/the-illusion-of-tdd.html) 89 | * [TDD is Dead. Long Live Testing.](http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html) 90 | 91 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/controllers.md: -------------------------------------------------------------------------------- 1 | # Controller Specs 2 | 3 | Rails 5 saw the deprecation of commonly used helper methods `assigns` and 4 | `assert_template`. It was deemed, and rightly so, that these methods lead to 5 | brittle tests that care too much about implementation details. 6 | 7 | Why should a test care that a specific instance variable was created or that a 8 | specific action file is responsible for the output of an action? In short, they 9 | shouldn't. 10 | 11 | The focus, upon advice from both Rails core and RSpec teams, has therefore 12 | shifted to more robust integration tests. 13 | 14 | You can read this [request specs guide](requests.mb) for a worked example. 15 | 16 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/features.md: -------------------------------------------------------------------------------- 1 | # Feature Specs 2 | 3 | We leverage feature specs to mimic the 'first user' of our application in an 4 | environment with as little stubbing as is possible. 5 | 6 | The specs will run through primary customer 'flows' to ensure that all the 7 | components of our app work well together and, most importantly, the consumer 8 | experiences the expected behaviour. 9 | 10 | Feature specs differ from unit specs, in that individual specs may have 11 | multiple expectations. 12 | 13 | An example of a feature spec is as follows: 14 | 15 | ```ruby 16 | require 'rails_helper' 17 | 18 | RSpec.feature 'subscribing to a the newsletter', js: true do 19 | before(:each) do 20 | ENV['MAILCHIMP_API_KEY'] = 'abc-def' 21 | ENV['MAILCHIMP_LIST_ID'] = '123' 22 | end 23 | 24 | context 'email is valid' do 25 | it 'subscribes the customer' do 26 | visit root_path 27 | 28 | fill_in 'newsletter_subscriber_email', with: 'tom@dvelp.co.uk' 29 | click_button 'Subscribe' 30 | 31 | expect(page).to have_content("You're in!") 32 | end 33 | end 34 | 35 | context 'email is invalid' do 36 | it 'does NOT subscribe the customer' do 37 | visit root_path 38 | 39 | fill_in 'newsletter_subscriber_email', with: 'tom-dvelp.co.uk' 40 | click_button 'Subscribe' 41 | 42 | expect(page).to have_content('Houston, we have a problem.') 43 | end 44 | end 45 | end 46 | ``` 47 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/helpers.md: -------------------------------------------------------------------------------- 1 | # Helper Specs 2 | 3 | With helpers being modules, their associated specs are typically low-level unit 4 | tests on the individual methods within. 5 | 6 | Example: 7 | 8 | ```ruby 9 | require 'rails_helper' 10 | 11 | RSpec.describe CustomersHelper, type: :helper do 12 | describe '#full_name(customer)' do 13 | context 'customer has a middle name' do 14 | it 'returns first middle and last names' do 15 | customer = FactoryGirl.build_stubbed( 16 | :customer, 17 | first_name: 'Tom', 18 | middle_name: 'Ruby', 19 | last_name: 'Mullen' 20 | ) 21 | 22 | result = helper.full_name(customer) 23 | 24 | expect(result).to eq('Tom Ruby Mullen') 25 | end 26 | end 27 | 28 | context 'customer does not have a middle name' do 29 | it 'returns first and last names' do 30 | customer = FactoryGirl.build_stubbed( 31 | :customer, 32 | first_name: 'Tom', 33 | last_name: 'Mullen' 34 | ) 35 | 36 | result = helper.full_name(customer) 37 | 38 | expect(result).to eq('Tom Mullen') 39 | end 40 | end 41 | end 42 | end 43 | ``` 44 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/mailers.md: -------------------------------------------------------------------------------- 1 | # Mailer Specs 2 | 3 | Mailer specs are often very terse and we focus on ensuring the following are as 4 | expected: 5 | 6 | * Subject line 7 | * From 8 | * To 9 | * Body 10 | 11 | ```ruby 12 | require 'rails_helper' 13 | 14 | RSpec.describe CustomerMailer, type: :mailer do 15 | describe 'welcome' do 16 | let(:mail) { CustomerMailer.welcome } 17 | 18 | it 'renders the headers' do 19 | expect(mail.subject).to eq('Welcome') 20 | expect(mail.to).to eq(['customer@dvelp.co.uk']) 21 | expect(mail.from).to eq(['team@dvelp.co.uk']) 22 | end 23 | 24 | it 'renders the body' do 25 | expect(mail.body.encoded).to match('Hi') 26 | end 27 | end 28 | end 29 | ``` 30 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/models.md: -------------------------------------------------------------------------------- 1 | # Model Specs 2 | 3 | ActiveRecord makes up the single largest part of the Rails framework, so it 4 | stands to reason that your model specs can have many components covering 5 | associations, delegations, scopes, validations etc. 6 | 7 | To help wrangle model specs and focus on the 'value add' more quickly, we 8 | recommend the following libraries: 9 | 10 | * [Shoulda Callback Matchers](https://github.com/jdliss/shoulda-callback-matchers) 11 | * [Shoulda Matchers](https://github.com/thoughtbot/shoulda-matchers) 12 | * [Test After Commit](https://github.com/grosser/test_after_commit) 13 | 14 | An example of a typical model spec at DVELP looks like this: 15 | 16 | ```ruby 17 | require 'rails_helper' 18 | 19 | describe Customer, type: :model do 20 | describe 'associations' do 21 | it { is_expected.to belong_to(:company) } 22 | it { is_expected.to have_many(:orders) } 23 | it { is_expected.to have_one(:address) } 24 | end 25 | 26 | describe 'callbacks' do 27 | it { is_expected.to callback(:parse_name).before(:validation) } 28 | end 29 | 30 | describe 'delegates' do 31 | it { is_expected.to delegate_method(:post_code).to(:address) } 32 | end 33 | 34 | describe 'nested attributes' do 35 | it { is_expected.to accept_nested_attributes_for(:orders) } 36 | end 37 | 38 | describe 'validations' do 39 | it { is_expected.to validate_presence_of(:company) } 40 | it { is_expected.to validate_presence_of(:email) } 41 | it { is_expected.to validate_uniqueness_of(:email) } 42 | it { is_expected.to validate_presence_of(:first_name) } 43 | it { is_expected.to validate_presence_of(:last_name) } 44 | end 45 | 46 | describe '.is_active' do 47 | it 'returns active customers' do 48 | active_customer = FactoryGirl.create(:customer, active: true) 49 | _inactive_customer = FactoryGirl.create(:customer, active: false) 50 | 51 | result = described_class.is_active 52 | 53 | expect(result).to match_array([active_customer]) 54 | end 55 | end 56 | 57 | describe '.activate' do 58 | it 'marks all records as active' do 59 | inactive_customer = FactoryGirl.create(:customer, active: false) 60 | 61 | expect { Customer.activate } 62 | .to change { inactive_customer.reload.active } 63 | end 64 | end 65 | 66 | describe '#full_name' do 67 | it 'is returns the customers full name' do 68 | customer = FactoryGirl.build_stubbed( 69 | :customer, 70 | first_name: 'Tom', 71 | last_name: 'Mullen' 72 | ) 73 | 74 | result = customer.full_name 75 | 76 | expect(result).to eq('Tom Mullen') 77 | end 78 | end 79 | end 80 | ``` 81 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/requests.md: -------------------------------------------------------------------------------- 1 | # Request Specs 2 | 3 | Request specs provide a thin wrapper around integration specs and are aimed at 4 | improving behavioural driven testing. By focusing on the inputs (inbound 5 | request) and outputs (end result), we can decouple the behaviour of the 6 | application from our implementation. 7 | 8 | It is advised to stub as little as possible when writing your specs in order to 9 | replicate the user experience as closely as you can. 10 | 11 | The following is an example of how a request spec can help achieve that: 12 | 13 | ```ruby 14 | require 'rails_helper' 15 | 16 | describe 'Updating a customer', type: :request do 17 | context 'customer is not authenticated' do 18 | it "denies access to customers#update" do 19 | customer = FactoryGirl.create(:customer) 20 | customer_attributes = { name: 'Tom' } 21 | 22 | expect { 23 | patch "/customers/#{customer.id}", { customer: customer_attributes } 24 | }.to_not change { customer.reload.name } 25 | 26 | expect(response).to redirect_to login_url 27 | end 28 | end 29 | 30 | context 'customer is authenticated' do 31 | it "allows access to customers#update" do 32 | customer = FactoryGirl.create(:customer) 33 | customer_attributes = { name: 'Bob' } 34 | 35 | authenticate(customer) 36 | 37 | expect { 38 | patch "/customers/#{customer.id}", { customer: customer_attributes } 39 | }.to change { customer.reload.name } 40 | 41 | expect(response).to redirect_to customer_url(customer) 42 | end 43 | end 44 | end 45 | ``` 46 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/services.md: -------------------------------------------------------------------------------- 1 | # Service Specs 2 | 3 | For each service, we would typically test it's public methods for expected 4 | behaviour, much like any other class. 5 | 6 | Example: 7 | 8 | ```ruby 9 | require 'rails_helper' 10 | 11 | RSpec.describe Customers::Creator do 12 | describe '#create' do 13 | it 'returns a customer object' do 14 | creator = described_class.new(params: customer_attributes) 15 | 16 | result = creator.create 17 | 18 | expected(result).to be_a(Customer) 19 | end 20 | 21 | context 'attributes are valid' do 22 | it 'creates a customer' do 23 | customer_attributes = FactoryGirl.attributes_for(:customer) 24 | creator = described_class.new(params: customer_attributes) 25 | 26 | expect { creator.create } 27 | .to change { Customer.count } 28 | end 29 | 30 | it 'sends a welcome email' do 31 | customer_attributes = FactoryGirl.attributes_for(:customer) 32 | creator = described_class.new(params: customer_attributes) 33 | 34 | allow(CustomerMailer).to receive(:welcome).and_call_original 35 | 36 | creator.create 37 | 38 | expect(CustomerMailer).to have_received(:welcome) 39 | .with(Customer.last) 40 | end 41 | end 42 | 43 | context 'attributes are invalid' do 44 | it 'creates a customer' do 45 | customer_attributes = {} 46 | creator = described_class.new(params: customer_attributes) 47 | 48 | expect { creator.create } 49 | .to change { Customer.count } 50 | end 51 | end 52 | end 53 | end 54 | ``` 55 | 56 | -------------------------------------------------------------------------------- /guides/code-style/templates/specs/views.md: -------------------------------------------------------------------------------- 1 | # View Specs 2 | 3 | We don't tend to use view specs as regularly for the following reasons: 4 | 5 | * Behaviour is covered by feature specs 6 | * Views should only contain basic logic 7 | * Views are implementation detail 8 | 9 | For those views where we do write specs, they would typically look like this: 10 | 11 | ```ruby 12 | require 'rails_helper' 13 | 14 | describe 'customers/show.html.slim' do 15 | it 'displays the customer name' do 16 | customer = build_stubbed(:customer) 17 | assign(:customer, customer) 18 | 19 | render 20 | 21 | rendered.should contain('Tom Mullen') 22 | end 23 | end 24 | ``` 25 | -------------------------------------------------------------------------------- /guides/dialogflow/agents-management.md: -------------------------------------------------------------------------------- 1 | # Dialogflow Agents Management 2 | 3 | DVELP uses Google [Dialogflow](https://dialogflow.com) technology to build natural language user interfaces. 4 | 5 | ## Create a New Agent 6 | 7 | Dialogflow is a part of [Google Cloud Platform](https://console.cloud.google.com), so to create a new agent you need to create a new project first. To do that follow the instructions below: 8 | 9 | 1. Go to [Google Cloud Platform](https://console.cloud.google.com) 10 | 2. In the top-left corner click on dropdown box 11 | 3. Select DVELP organization. 12 | 4. Click on "NEW PROJECT" 13 | 5. Set project name. N.B. Project name should be equivalent to Dialogflow agent name 14 | 6. Make sure Location is "dvelp.co.uk" 15 | 7. Click "Create" 16 | 8. Go to [Dialoflow console](https://console.dialogflow.com) 17 | 9. Click on Agents select box and choose "Create new agent" option 18 | 10. Set agent name 19 | 11. Choose Google project which we created before 20 | 12. Optionally choose time zone 21 | 13. Click "Create" 22 | 23 | That's it. Sometimes bot creation takes few minutes. 24 | 25 | ## Get Dialogflow API Credentials 26 | 27 | To connect Dialogflow agent to your API you have to get credentials as follows: 28 | 29 | 1. Go to Dialogflow agent configuration 30 | 2. Click on Project ID link 31 | 3. Click on navigation menu 32 | 4. Go to IAM & Admin -> Service Accounts 33 | 5. Find "Dialogflow Integrations" in "Name" column 34 | 6. Click on 3 dots in "Actions" column -> Create Key 35 | 7. Choose JSON 36 | 8. Click Create 37 | 38 | After this your browser will download service account key. 39 | 40 | ![Dialogflow API Credentials](../../assets/GCP_keyfile.gif) 41 | -------------------------------------------------------------------------------- /guides/dialogflow/ruby-client-for-dialogflow-api.md: -------------------------------------------------------------------------------- 1 | # Ruby Client for Dialogflow API 2 | 3 | Google cloud provides [Ruby Client for Dialogflow API](https://github.com/googleapis/google-cloud-ruby/tree/master/google-cloud-dialogflow). Before using this gem you may need to [create an agent and get special credentials](agents-management.md). 4 | 5 | ## Gem Installation 6 | 7 | Add this line to your Gemfile 8 | 9 | `gem 'google-cloud-dialogflow'` 10 | 11 | Then create `config/initializers/google_cloud_dialogflow.rb` 12 | 13 | `require 'google/cloud/dialogflow/v2'` 14 | 15 | ## Gem Usage 16 | 17 | This is a class example which allows developers to detect intent by text or event. It requires the following arguments 18 | 19 | - `keyfile_json` - content of keyfile.json file. See [this article](agents-management.md) to check how to get it 20 | - `parameters` - hash of configurations. It allows you to set following parameters: 21 | - `:language_code` - for example `en-GB` 22 | - `:environment` - Dialogflow environment to use. Leave it blank if you don't use this feature 23 | - `:contexts` - array of contexts to be attached to the request 24 | - `session` - unique string, e.g. Twilio call Sid 25 | - `utterance` - user's input or event name which you are going to use to detect intent 26 | 27 | 28 | ``` 29 | module Dialogflow 30 | class SessionsClient 31 | def initialize(keyfile_json:, parameters: [], session:, utterance:) 32 | self.keyfile_json = keyfile_json 33 | self.parameters = parameters 34 | self.session = session 35 | self.utterance = utterance 36 | end 37 | 38 | def detect_text_intent 39 | @detect_text_intent ||= sessions_client.detect_intent( 40 | session_string, 41 | { 42 | text: { 43 | text: utterance, 44 | language_code: language_code 45 | } 46 | }, 47 | query_params: { contexts: contexts } 48 | ) 49 | end 50 | 51 | def detect_event_intent 52 | @detect_event_intent ||= sessions_client.detect_intent( 53 | session_string, 54 | { 55 | event: { 56 | name: utterance, 57 | language_code: language_code 58 | } 59 | }, 60 | query_params: { contexts: contexts } 61 | ) 62 | end 63 | 64 | private 65 | 66 | attr_accessor :keyfile_json, :parameters, :session, :utterance 67 | 68 | def environment_string 69 | environment_enabled? ? "environments/#{environment}/users/-/" : '' 70 | end 71 | 72 | def environment_enabled? 73 | parameters[:environment].present? 74 | end 75 | 76 | def environment 77 | parameters[:environment].presence || '-' 78 | end 79 | 80 | def language_code 81 | parameters[:language_code] 82 | end 83 | 84 | def session_string 85 | "projects/#{keyfile['project_id']}/agent/#{environment_string}" \ 86 | "sessions/#{session}" 87 | end 88 | 89 | def keyfile 90 | @keyfile ||= JSON.parse(keyfile_json) 91 | end 92 | 93 | def contexts 94 | parameters[:contexts].to_a.map do |context| 95 | { 96 | lifespan_count: 1, 97 | name: "#{session_string}/contexts/#{context}", 98 | parameters: {} 99 | } 100 | end 101 | end 102 | 103 | def sessions_client 104 | @sessions_client = Google::Cloud::Dialogflow::V2::SessionsClient.new( 105 | credentials: keyfile 106 | ) 107 | end 108 | end 109 | end 110 | ``` 111 | 112 | Both methods `detect_text_intent` and `detect_event_intent` will return instance of [`Google::Cloud::Dialogflow::V2::DetectIntentResponse`](https://googleapis.github.io/google-cloud-ruby/docs/google-cloud-dialogflow/latest/Google/Cloud/Dialogflow/V2/DetectIntentResponse.html). So, to get response parameters such as `whisper_message`, you can use: 113 | ``` 114 | result.query_result.parameters.fields['whisper_message'].string_value 115 | ``` 116 | 117 | ## Other Links 118 | 119 | For more information visit https://googleapis.github.io/google-cloud-ruby/docs/google-cloud-dialogflow/latest/Google/Cloud/Dialogflow/V2/SessionsClient.html 120 | -------------------------------------------------------------------------------- /guides/environments/Readme.md: -------------------------------------------------------------------------------- 1 | # Environments 2 | 3 | Consistency in approach is key to building and maintaining 100s of applications 4 | efficiently. It dramatically reduces the cost of switching and prevents silos of 5 | knowledge in projects or teams. 6 | 7 | ## Resources 8 | 9 | * [Circle CI 2 Configuration]('circle-ci-2.md') 10 | * [Deploying to Shopify]('deploying-shopify.md') 11 | * [Diagnostics]('diagnostics.md') 12 | * [Heroku Pipeline]('heroku-pipeline.md') 13 | 14 | ## Setup 15 | 16 | The following is a typical environment setup that we use to build, deploy and 17 | maintain our applications. 18 | 19 | As a rule, production data is never used on the local, development, and staging 20 | environments. 21 | 22 | ### Local/Dev 23 | 24 | This will be your local environment. Typically on a local machine, but could be on a local network. 25 | 26 | Anything goes in `dev`, it's yours to do what you want. 27 | 28 | We recommend [ngrok]('https://ngrok.com/') to expose public tunnels 29 | to localhost for speedy development work of APIs or with distributed teams. 30 | 31 | 32 | ### Staging 33 | 34 | Staging is a publicly accessible environment and is designed to mirror 35 | production as closely as possible. 36 | 37 | We recommend all resources associated with staging are appended with `-staging` 38 | e.g. `dvelp-staging`, where `dvelp` is the name of the git repo. 39 | 40 | External resources, for example Sentry, should also mirror this naming 41 | convention. 42 | 43 | ### Production 44 | 45 | The real deal. This is the holy grail and should be treated with ulitimate 46 | respect. 47 | 48 | Live data, live traffic. 49 | 50 | In alignment with `staging`, all resources should be appended with 51 | `-production` e.g. `dvelp-production`. 52 | 53 | 54 | -------------------------------------------------------------------------------- /guides/environments/deploying-shopify.md: -------------------------------------------------------------------------------- 1 | # Developing and Deploying to Shopify 2 | 3 | ## The Challenge 4 | 5 | The primary challenge we faced when developing for Shopify was that the codebase checked in to Git was getting out of sync with the codebase deployed to Shopify. This issue was compounded when using the same theme on multiple stores e.g. for simple staging + production environments or in more complex, multi-geo scenarios. 6 | 7 | The root of the issue revolves around Shopify's lack of support for nested 8 | folders. Amongst other things, this presents challenges with: 9 | 10 | * Imagery and user defined settings 11 | * Javascript and stylesheet compilation 12 | 13 | ## The Solution 14 | 15 | 1) [Ignore compiled assets](../scripts/shopify/.gitignore) from SCM 16 | 17 | 2) Set-up [Grunt](../scripts/shopify/gruntfile.js) to sync, process and compile assets 18 | 19 | 3) [Deploy](#deployment) to Shopify 20 | 21 | ## Deployment 22 | 23 | To facilate deployment and improve syncing between store and code base, we configured the CI server, in this case CircleCI, to manage all of the deployments for us. We hooked up the `master` branch to deploy direct to the production store and the `staging` branch to the staging store. 24 | 25 | ### Tools 26 | 27 | * [Circle](http://circleci.com/) 28 | * [Grunt](http://gruntjs.com/) 29 | * [Grunt Shopify](https://github.com/wilr/grunt-shopify) 30 | 31 | ### Setup 32 | 33 | * Add the application to the CircleCI 34 | * Create a `circle.yml` file in the root of the application and add it to GIT 35 | * Add the following config to `circle.yml` 36 | ``` 37 | deployment: 38 | production: 39 | branch: master 40 | commands: 41 | - grunt deploy 42 | staging: 43 | branch: staging 44 | commands: 45 | - grunt deploy 46 | ``` 47 | 48 | * Update `gruntfile.js` file to read the Shopify credentials from the environment variables: 49 | ``` 50 | if(process.env.IS_CI) { 51 | if(process.env.CIRCLE_BRANCH == 'master') { 52 | var environment = 'PRODUCTION'; 53 | } else { 54 | var environment = 'STAGING'; 55 | } 56 | var localConfig = {}; 57 | localConfig[':api_key'] = process.env[environment + '_SHOPIFY_API_KEY']; 58 | localConfig[':password'] = process.env[environment + '_SHOPIFY_PASSWORD']; 59 | localConfig[':store'] = process.env[environment + '_SHOPIFY_STORE']; 60 | } else { 61 | var localConfig = yaml.safeLoad(fs.readFileSync('./config.yml', 'utf8')); 62 | } 63 | ``` 64 | 65 | The `IS_CI` variable determines that we are deploying via CI, in which case we read data from the environment variables rather then from a local `config.yml` file, which is used for manual deployment. 66 | 67 | ### CircleCI Variables 68 | 69 | * `STAGING_SHOPIFY_API_KEY` 70 | 71 | * `STAGING_SHOPIFY_PASSWORD` 72 | 73 | * `STAGING_SHOPIFY_STORE` 74 | 75 | * `PRODUCTION_SHOPIFY_API_KEY` 76 | 77 | * `PRODUCTION_SHOPIFY_PASSWORD` 78 | 79 | * `PRODUCTION_SHOPIFY_STORE` 80 | 81 | ## Get 'em 82 | We've added the complete set of files [here](../scripts/shopify) for your reference. 83 | -------------------------------------------------------------------------------- /guides/environments/diagnostics.md: -------------------------------------------------------------------------------- 1 | # Diagnostics 2 | Shipping apps to a production environment is paramount in our development cycle. Having the correct tools in place to monitor and diagnose issues is essential. 3 | 4 | The following is the baseline setup for logging and error tracking in Rails applications at DVELP. 5 | 6 | ## Naming 7 | 8 | Make sure you have the same names for Heroku application, sentry project and papertrail system e.g. `dvelp-production`. Consistency in naming conventions is very important. 9 | 10 | ## Logging 11 | 12 | ### Papertrail 13 | 14 | For consistency and consolidation, we use a corporate [Papertrail](https://papertrailapp.com) account for logging purposes. 15 | 16 | ### Setup 17 | 18 | This [guide](https://papertrailapp.com/systems/setup?type=app&platform=heroku) will help you get Papertail set up on Heroku environments. 19 | 20 | ### Lograge 21 | 22 | To prevent overly verbose logs, we recommend using [lograge](https://github.com/roidrage/lograge) to filter out the noise and provide more clarity. 23 | 24 | ```ruby 25 | # config/initializers/lograge.rb 26 | 27 | Rails.application.configure do 28 | config.lograge.enabled = Rails.env.production? 29 | config.lograge.custom_options = lambda do |event| 30 | exceptions = %w[controller action format] 31 | { 32 | params: event.payload[:params].except(*exceptions) 33 | } 34 | end 35 | end 36 | ``` 37 | 38 | If you’re using Rails 5's API-only mode and inherit from `ActionController::API`, you must define it as the controller base class which lograge will patch: 39 | 40 | ```ruby 41 | config.lograge.base_controller_class = 'ActionController::API' 42 | ``` 43 | 44 | Use `info` log level to remove unnecessary debugging logs. 45 | 46 | ```ruby 47 | # config/environments/production.rb 48 | 49 | config.log_level = :info 50 | ``` 51 | 52 | ## Error Handling 53 | 54 | We equally have a corporate [Sentry](https://sentry.io) account for error handling. Sentry is a service designed to help you monitor application issues in realtime. 55 | 56 | ### Setup 57 | Complete the following steps to setup Sentry in your application: 58 | 59 | - Create [new project](https://sentry.io/organizations/dvelp/projects/new) on the DVELP corporate account 60 | - Add `gem 'sentry-raven'` to your Gemfile and run `bundle install` 61 | - Set `SENTRY_DSN` ENV variable. Sentry will give you this when creating a new project (step 1). 62 | - Set `SENTRY_ENVIRONMENT` ENV variable accordingly. 63 | 64 | To make sure your application doesn't send any confidential information like passwords, set sanitize fields: 65 | 66 | ``` 67 | # config/initializers/sentry.rb 68 | 69 | Raven.configure do |config| 70 | config.sanitize_fields = Rails.application.config 71 | .filter_parameters.map(&:to_s) 72 | config.current_environment = ENV.fetch('SENTRY_ENVIRONMENT', 'production') 73 | end 74 | ``` 75 | 76 | Also, the last `config` line allows you to set the proper environment to your Sentry project. 77 | 78 | ### Testing 79 | 80 | To send a test event after setting up Sentry in your application, run the following command: 81 | 82 | `rails raven:test` 83 | 84 | And for Heroku: 85 | 86 | `heroku run rails raven:test --remote ` 87 | 88 | ### Slack integration 89 | 90 | Don't forget to add notifications to your project Slack channel. To enable this feature go to Sentry project settings and choose 'Alerts' section. 91 | -------------------------------------------------------------------------------- /guides/environments/heroku-pipeline.md: -------------------------------------------------------------------------------- 1 | # Adding apps to Heroku pipeline 2 | 3 | ## Prerequisites: 4 | 5 | ### Verified account 6 | 7 | Means you need to have your credit card details added to your account: [https://dashboard.heroku.com/account/billing](https://dashboard.heroku.com/account/billing) 8 | 9 | ### Staging app 10 | 11 | If you don't have staging app, create it by forking the production app using the following command `heroku fork --from ${app_name} --to ${app_name}-staging [--skip-pg]`(* - check fusnote) [1] 12 | 13 | * Note that `${app_name}-staging` app must **NOT** exist already 14 | * Use staging app as default app for heroku CLI commands: [2] 15 | 16 | ``` 17 | git remote rename heroku heroku-production 18 | git remote add heroku https://git.heroku.com/${app_name}-staging.git 19 | git config heroku.remote heroku # use 'heroku' remote as default for heroku CLI 20 | ``` 21 | 22 | * Last command is **very important**! Without it, your default app will be production (or any `$ heroku` command will fail). To make sure it's set up correctly, run: `heroku info`. First line of the output should say: `=== {app_name}-staging` 23 | 24 | * The above command **copies** all database **data** to a new database and all config vars. 25 | * The database data is not copied if `--skip-pg` is passed as an option 26 | * To reduce costs of your **newly created** database run: [3] [4] 27 | 28 | ``` 29 | heroku addons:create heroku-postgresql:hobby-dev # [3] 30 | heroku config 31 | heroku pg:copy DATABASE_URL HEROKU_POSTGRESQL_${colour}_URL --confirm ${app_name}-staging # [4] 32 | heroku pg:promote HEROKU_POSTGRESQL_{colour} 33 | heroku addons:destroy HEROKU_POSTGRESQL_${old_db_colour} --confirm ${app_name}-staging 34 | ``` 35 | Note that `${colour}` represents the colour of your newly created postgresql database, while `${old_db_colour}` represents the colour of your old database. 36 | 37 | * Update config vars as needed 38 | * Remember to update carrierwave AWS S3 39 | 40 | * If you don't need SSL addon, remove it `heroku addons:destroy ssl` 41 | * Staging app is now in **your ownership**. Any charges will happen on your account. Change staging app permissions if needed (add users, transfer ownership, etc.). 42 | * First add users, then transfer ownership, as the later will impede your access to adding users. 43 | * `heroku sharing:add ${collaborator}@dvelp.co.uk -a ${app_name}-staging` 44 | * `heroku sharing:transfer ${collaborator}@dvelp.co.uk -a ${app_name}-staging` 45 | 46 | ### heroku-pipelines addon for Heroku Toolbelt 47 | 48 | * Install it by executing `heroku plugins:install heroku-pipelines` 49 | 50 | ## Setup 51 | 52 | 1. Create the pipeline (from the app directory): [5] 53 | 54 | `heroku pipelines:create ${pipeline_name}` 55 | 56 | It's good to call the `${pipeline_name}` similar or the same as production app name. 57 | 58 | 2. Add production app to the pipeline: 59 | 60 | `heroku pipelines:add -a ${app_name} ${pipeline_name}` 61 | 62 | ## Promote! 63 | 64 | Below command will promote the `${app_name}-staging` (staging app) to `${app_name}` (production): 65 | `heroku pipelines:promote -a ${app_name}-staging` 66 | 67 | ### FAQ 68 | 69 | #### Can I run scripts, such as rake db:migrate when promoting? 70 | 71 | No, not at this time. 72 | 73 | ## Sources 74 | 75 | 1. [Fork app](https://devcenter.heroku.com/articles/fork-app) 76 | * [Heroku Toolbet default app](http://stackoverflow.com/questions/17497947/is-there-a-way-to-set-heroku-toolbet-default-app) 77 | * [Heroku Postgresql Addon](https://elements.heroku.com/addons/heroku-postgresql#addon-plans) 78 | * [Upgrading Heroku Postgres Databases](https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases) 79 | * [Heroku Pipelines](https://devcenter.heroku.com/articles/pipelines) 80 | 81 | 82 | ***** 83 | 84 | * 85 | ###### Note that you can set shell variables like this `app_name="braid-mackenzie"`, and run most of the commands without having to change anything. Here's the list of variables needed: 86 | 87 | ``` 88 | app_name="" 89 | collaborator="" 90 | pipeline_name="" 91 | colour="" 92 | old_db_colour="" 93 | ``` 94 | -------------------------------------------------------------------------------- /guides/marketing/social-media-policy.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | # Social media policy 4 | 5 | ## Be nice, and connect 6 | 7 | Social media is an important channel for us to demonstrate one of our biggest strengths: our highly skilled team members. 8 | By taking part of the conversation you have the power to promote the DVELP brand and build your own personal brand at the same time. 9 | We provide copywriting and design resources if you feel you have a great idea, but are not sure how to best share. 10 | 11 | Few guidelines to follow: 12 | * Verify your claims and use data to support it whenever possible 13 | * Keep your interactions conversational yet professional and tasteful 14 | * Link back to the DVELP [website](https://dvelp.co.uk/), especially to case studies whenever possible 15 | * Follow the law 16 | * Protect information, both our own and of our clients. Verify that we are approved to talk about a client project before doing so 17 | * Be humble - Never make a negative or offensive comment 18 | * Be conscious when mixing your business and personal lives 19 | * What you share is visible forever - When in doubt, do not post 20 | 21 | 22 | ## Our most important social media channels 23 | 24 | [Linkedin](https://www.linkedin.com/company/dvelp/) 25 | Follow the page and support marketing efforts by liking and sharing DVELP posts. 26 | Reach out to marketing if you feel you have content to share through the DVELP page. 27 | Take opportunities to comment on relevant posts in your network. 28 | 29 | [Twitter](https://twitter.com/DVELP_team) 30 | Follow, love, share if you are connected with your professional network on Twitter. We love sharing, but want to avoid spamming our friends with non-relevant content. 31 | 32 | [Glassdoor](https://www.glassdoor.co.uk/Overview/Working-at-Dvelp-EI_IE3186528.11,16.htm) 33 | Share how it feels to be working for DVELP. This helps the right talent to find us and decide at an early stage if there is a good cultural fit. 34 | 35 | [Youtube](https://www.youtube.com/channel/UCfHkkr-rl1mmukN7rTQcIEw) 36 | Subscribe to this channel to see how we talk about our work at industry events. You are also welcome to share your business relevant thoughts in a talking head clip or a screen capture video. Reach out to marketing to discuss how to make it happen. 37 | 38 | [Quora](https://www.quora.com/topic/DVELP) 39 | Follow topics like [Twilio](https://www.quora.com/topic/Twilio) and [Dialogflow](https://www.quora.com/topic/Dialogflow) to see relevant questions. Give relevant and concise answers and point the reader to the relevant part of the DVELP website for further details. 40 | 41 | [Stackoverflow](https://stackoverflow.com/) 42 | This place is for you to shine as an individual expert. Show the best version of yourself. If you want to use this channel for brand support, talk about your role at DVELP on your bio page. 43 | 44 | 45 | ## Dealing with negative posts 46 | 47 | Let the subject matter experts respond to negative posts. You may come across negative posts about the Company or its brands, or see third parties trying to spark negative conversations. 48 | 49 | Unless you are clearly the expert of the field, avoid the temptation to react yourself. Instead pass the post(s) along to marketing or share with the subject matter experts. 50 | -------------------------------------------------------------------------------- /guides/project-process/bug-classifications.md: -------------------------------------------------------------------------------- 1 | # Bug Classifications 2 | 3 | Bugs happen, make sure you've setup the right diagnostic tools to catch them. Instructions for that can be found in the [Diagnostics](/guides/environments/diagnostics.md) section. 4 | 5 | Once a bug has been reported it should be classified using the following definitions so we can decide how to prioritse them. 6 | 7 | 8 | | Bug Classification | Definition | 9 | |------------------- | -----------| 10 | | P1 | The defect affects critical functionality or critical data. It does not have a workaround. E.g. Payment cannot complete, item cannot be purchased, account cannot be created, complete failure of a feature. 11 | | P2 | The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. E.g. A feature is not functional from one page but the task is doable if 10 complicated indirect steps are followed in a separate flow. 12 | | P3 | The defect affects minor functionality or non-critical data. It has an easy workaround. E.g. A minor feature that is not functional in one page but the same task is easily doable from another page. 13 | -------------------------------------------------------------------------------- /guides/project-process/commercial-terms.md: -------------------------------------------------------------------------------- 1 | # Commercial Terms 2 | 3 | ## Invoice Terms for Professional Services 4 | 5 | We request a down-payment for the first 2 weeks to start working. 6 | 7 | After the first 2 weeks, invoices will be sent weekly on a Monday for the 8 | previous week’s work. 9 | 10 | ## DVELP Professional Services Fees 11 | 12 | Our professional services are provided on a time and materials basis. 13 | 14 | Fees are exclusive of the below expenses. These expenses are chargeable. 15 | 16 | * For travel to and from client side further than 2 hours from our office: 17 | * Travel cost 18 | * Travel time (chargeable at the hourly rate for professional services) 19 | * Accommodation for overnight stays 20 | * Subsistence 21 | * Any other reasonable expenses incurred in connection with the provision of our 22 | services 23 | 24 | -------------------------------------------------------------------------------- /guides/project-process/continuous-improvement-support-and-hosting.md: -------------------------------------------------------------------------------- 1 | # Continuous Improvement, Support & Hosting 2 | 3 | Ahead of [deploying a project to a live environment](/guides/project-process/go-live-checklist.md), 4 | it's important to agree and organise continuous improvement, support and hosting. 5 | 6 | ## Continuous Improvement 7 | 8 | We believe that meaningful change and business value is delivered at the intersection between bold, fast-paced processes, and modern technology that facilitates them. 9 | 10 | The platforms we build are flexible, extensible and facilitate continuous delivery. We approach improvements to the platform with the same process used in the initial delivery, broken down into 10-12 week cycles aimed at delivering against a set of clearly defined business objectives. 11 | 12 | We work with agility to test and deploy better solutions, both for the customer and the business in short, high-value cycles. Our philosophy is to provide platforms that appreciate in value over time. For us, production deployment is only the first step in the journey. 13 | 14 | DVELP’s Continuous Improvement is provided as a service with an expert team whose focus is to deliver against a long term strategy, post production launch. 15 | 16 | ## Support 17 | 18 | Our support packages allow us to be on-hand to help resolve any unexpected, 19 | unplanned issues that arise with your application. 20 | 21 | Our support agreements come in the following packages. 22 | 23 | | | Base | Plus | Enterprise | 24 | | ------------------------------------------------ | -------------------------- | -------------------------- | ---------------- | 25 | | Monthly Cost | £1000 | £2500 | £5000 | 26 | | Email Support | Yes | Yes | Yes | 27 | | Telephone Support | Business day (8am-6pm) GMT | Business day (8am-6pm) GMT | 24/7 | 28 | | *Response Times* | | | | 29 | | [P1 - Business Critical](bug-classifications.md) | 5 business hours | 2 business hours | 1 hour | 30 | | [P2 - Degraded Service](bug-classifications.md) | 8 business hours | 4 business hours | 2 hours | 31 | | [P3 - General Issue](bug-classifications.md) | 10 business hours | 6 business hours | 5 business hours | 32 | 33 | Support packages do not cover the professional services time & materials 34 | required to resolve an issue. Professional services are charged per hour, at a 35 | pre-agreed rate, with a 1 hour minimum call out charge. 36 | 37 | Where possible, we will attempt to resolve any reported issue before engaging 38 | an engineer. 39 | 40 | 41 | Support contracts are paid up-front and the minimum contract length is 12 42 | months. 43 | 44 | 45 | ## Hosting 46 | 47 | We offer fully-managed, hosting packages. Packages come in the following plans 48 | to suit the need of the project or application. 49 | 50 | | Package | Detail | Cost (pcm) | 51 | | ------------ | ------------------------------------------------------------------------ | -------------------- | 52 | | Basic | Single environment deployment (e.g. production only) | £180 per application | 53 | | Pipeline | Dual environment deployment (e.g. staging and production) | £250 per application | 54 | | Pipeline Pro | Triple environment deployment (e.g. development, staging and production) | £425 per application | 55 | 56 | N.B. All packages include logging, through [Papertrail](https://papertrailapp.com/) and error tracking, through [Sentry](https://sentry.io/). 57 | 58 | We run our applications on Heroku and will pass on their [customer promise](https://www.heroku.com/policy/promise). 59 | -------------------------------------------------------------------------------- /guides/project-process/design-guidelines.md: -------------------------------------------------------------------------------- 1 | ## DVELP Design Guidelines 2 | If you are a designer working with us on a project, there are a few simple guidelines you should follow to help things run smoothly. 3 | 4 | ### Format 5 | We prefer to receive design files in Photoshop's `.psd` format. 6 | 7 | Iconography should be sent to us in `.ai`. If that isn't possible than please use the `.svg` format. 8 | 9 | ### Laptop & Mobile 10 | Designs should not exceed `1920-2000px` for the whole page and `1200-1400px` for the content to achieve good fit on laptops. 11 | 12 | Mobile should scale down to fit in `320px` (iPhone 5). We recommend following this standard breakpoint grid: 13 | 14 | ``` 15 | Small: 320-639px 16 | Medium: 640px 17 | Large: 1024px 18 | XLarge: 1200px 19 | XXLarge: 1440px 20 | ``` 21 | ### Image Optimisation 22 | The most important thing, in a word, is **compression**. To reduce load times please use only as many pixels as are necessary. Images should be heavily optimised. JPEG is preferred to PNG. 23 | 24 | Check out Dan Barber's great [guide](https://robots.thoughtbot.com/the-complete-guide-to-optimising-web-images) to image optimisation for detailed best practice. 25 | 26 | ### Design Guide 27 | A simple [design style guide](https://designschool.canva.com/blog/50-meticulous-style-guides-every-startup-see-launching/) for the app is optional but useful. It makes our lives easier to have a guide with text elements and title standards defined for use across the whole app. 28 | 29 | 30 | ### Client Preview 31 | We use [Invision](https://www.invisionapp.com/) to show designs to clients. This means we need a `.jpg` version of anything requiring client sign-off. 32 | 33 | ### Notes 34 | If you hit a wall or have a question please drop us a line. While some projects have narrow briefs, we often have leeway for great ideas so don't be shy. 35 | 36 | -------------------------------------------------------------------------------- /guides/project-process/go-live-checklist.md: -------------------------------------------------------------------------------- 1 | # Go Live Checklist 2 | 3 | A Go Live Checklist should be added to every project trello board to ensure we all understand what has to be done before a project can go live. 4 | 5 | The card should be added at project kick off and be personalised for the project. 6 | It should be reviewed at least once a sprint. 7 | 8 | 9 | ## Checklist 10 | 11 | - [ ] Continuous Improvement, Support and Hosting [plans](continuous-improvement-support-and-hosting.md) agreed 12 | - [ ] Rollout Plan agreed with stakeholders 13 | - [ ] Scoped requirements have been fully tested in staging (happy and unhappy paths) 14 | - [ ] Error tracking setup [Sentry](/guides/environments/diagnostics.md#error-handling) and being sent to the right places 15 | - [ ] Ensure production environment does not point to any dev or staging environments/services 16 | - [ ] Required reporting setup and being monitored appropriately 17 | - [ ] Handover documentation (technical and instructions for end users) 18 | - [ ] Required training for users has been completed 19 | - [ ] Rollback plans defined 20 | - [ ] Security requirements are met (these are defined as part of the kick-off meeting) 21 | - [ ] Escalation process defined and shared with the client 22 | - [ ] Plan for how future production releases are handled 23 | 24 | ## Go Live Plan 25 | 26 | For each major feature release to a production environment, we recommend you 27 | summarise the roll out plan in a document like 28 | [this](https://docs.google.com/document/d/1K7tO3CFhQkJ7L-HIKlmieUh6fo6Wh-R64vk-9Ri_bcU/edit?usp=sharing). 29 | -------------------------------------------------------------------------------- /guides/project-process/harvest-forecast.md: -------------------------------------------------------------------------------- 1 | # Harvest Forecast 2 | A quick guide to planning resources in Harvest Forecast at DVELP. 3 | 4 | ## So what is it? 5 | Harvest Forecast is a web-based resource planning tool for allocating expected work time across multiple users and projects. It syncs with Harvest, conveniently allowing for comparisons of planned vs. actual hours worked. 6 | 7 | ## How do we use it at DVELP? 8 | We take a bottom up approach to planning at DVELP. We trust in the team's expertise to estimate how much time they need for the work on hand. 9 | 10 | In the **Projects** view, Team members are added to their active projects for their expected hours effort per day needed. We plan in support for active projects against that project directly, particularly for the critical time after launch. We also have team members planned for general ongoing support to catch the odd help request from our long term clients. Public holidays and vacations are accounted for, as are internal R&D projects. 11 | 12 | We target having the team planned at 80% of capacity to allow some contingency in case of illness or last minute requests. 13 | 14 | When the dust settles, we look at the **Team** view to see if anyone has too much or too little on their plate and work with everyone to share the load. 15 | 16 | ## Planning Flow 17 | New requests and changes are planned into Forecast daily. Any changes to the current week are reviewed with the impacted teams in real time. 18 | 19 | Full projects are estimated and planned in their entirety. Small improvement works (<2 days) are planned in detail across the next two weeks. 20 | 21 | Every Friday we review the past week and discuss the upcoming week with the team so that everyone is on the same page and ready to roll first thing Monday morning. 22 | 23 | -------------------------------------------------------------------------------- /guides/project-process/roles-and-responsibilities.md: -------------------------------------------------------------------------------- 1 | # Roles and Responsibilities 2 | 3 | We define the below roles that are played by different members of the project team on each project. 4 | 5 | There is not necessarily an overlap between employment title and role title. This means that, for example, a Project Manager could play the role of an Account Manager. In fact, multiple roles can be played by the same person. 6 | 7 | ## Role Assignments 8 | 9 | To understand who holds which role on which project, please consult [The Projects Spreadsheet](https://docs.google.com/spreadsheets/d/1XmG-CRlNz_mxuX7pf_OIogWIRXWqnxQQF4GaTTXmtoM/edit#gid=0). 10 | 11 | ### Sales Manager 12 | * Generating new business from new logos 13 | * Drafting and sending out proposals for new business 14 | * Draft MSA and relevant Addendums and ensure they are signed and filed in the right place 15 | * Ensure a maintenance contract is in place before completion of the project 16 | * Obtain first purchase order 17 | * Ensure that downpayment is agreed and paid by the client before work commences (Ruby to be the one that create the associated invoice) 18 | * Create a project in Harvest with correct billing and team information 19 | 20 | ### Account Manager 21 | * Growing our existing accounts 22 | * Drafting and sending out proposals for follow-on pieces of work 23 | * Agree who travels to client site when, ensure relevant individuals are happy to travel 24 | * Should further Purchase Orders be required, ensure they are obtained in time for on-going invoicing 25 | * Ensure the timely invoicing of our customers by providing Ruby with the inputs she needs to create and send invoices. Review draft invoices before they're sent. 26 | * Discuss with Marketing Manager what marketing material can be created from this project as a case study 27 | * Ensure that support and maintenance requests are appropriately serviced 28 | 29 | ### Marketing Manager 30 | * Generating Marketing Qualified Leads (MQL) 31 | * DVELP's branding 32 | * Our presence at industry events 33 | * The content we deliver all communiation channels 34 | * Quality of our website 35 | 36 | ### Line Manager 37 | * The professional development of line managees 38 | * First point of contact on all questions line managees have 39 | * Monthly "coffee chat" with line managees on progression towards goals, any concerns and/or ideas about DVELP and our processes 40 | * Conducting [goal reviews](../handbook/../../handbook/professional-development/external-training-courses.md) 41 | * Signing off on line managees' holiday requests after checking with affected parties 42 | 43 | ### Project Manager 44 | * Delivering project to agreed upon client requirements and timeline 45 | * Client satisfaction 46 | * Organise and lead the internal kick-off meeting 47 | * Organise and lead the external kick-off meeting 48 | 49 | ### Tech Lead 50 | * Responsible for the technical delivery of the project 51 | * Ensures excellence in the quality of our code 52 | * Maintaining DVELP's technical standards such as 53 | * Linting 54 | * Tests 55 | * Code reviews 56 | 57 | ### Scrum Master 58 | * Scheduling and running sprint ceremonies on a project throughout the project lifecycle 59 | * Ensuring every developer on the project team knowing what they are responsible for delivering 60 | 61 | ### Support Lead 62 | * Ensuring that support and maintenance requests are appropriately serviced -------------------------------------------------------------------------------- /guides/project-process/running-a-demo.md: -------------------------------------------------------------------------------- 1 | # Running a Demo 2 | 3 | Demos are a fundamental part of our core belief to 'show value early'. 4 | 5 | Running a demo helps to show progress, keeps the team informed and builds trust 6 | with the client. 7 | 8 | The following is a guide to help the demo run smoothly. 9 | 10 | ## Set an Objective 11 | 12 | Clarify the objective for the session. The objective shoudld explain why this demo is important and what the attendees will gain from participating. 13 | 14 | i.e. how the demo delivers against a feature or project requirement 15 | 16 | *Make sure you clarify this objective when the demo starts.* 17 | 18 | Bonus points for associating the subject of the demo to a business objective. 19 | 20 | ## Recap the Steps 21 | 22 | Clarify the steps, features or functionality you are going to run through. When 23 | planning these steps, make sure they deliver against the objective. 24 | 25 | *Make sure you spell these out after you have explained the objective.* 26 | 27 | ## Practice 28 | 29 | Practice makes perfect. Before any demo, make sure you have done a dry-run so 30 | you are comfortable and confident of the flow. 31 | 32 | ## Be Prepared 33 | 34 | Demos often require information from other sources like customer reference 35 | numbers, or phone numbers. Make sure you have them to hand so you don't have to 36 | scramble to find them during the session. 37 | 38 | ## Get Excited 39 | 40 | This is your time to show-off your hard work. You are well prepared, well practiced so time to get excited. The more enthusiastic you are, the better! 41 | -------------------------------------------------------------------------------- /guides/project-process/scrum-process.md: -------------------------------------------------------------------------------- 1 | # SCRUM Process 2 | 3 | Scrum is the most common Agile delivery process. For this process we need people to be Scrum Masters. 4 | Scrum Masters ensure the ceremonies happen in the right way at the right time. 5 | It is important to note that the full Scrum Process is not needed for all our projects (eg IC&A). It is the project manager's decision how it is implemented. 6 | 7 | 8 | ## Ceremonies 9 | 10 | The Scrum Process comprises the below ceremonies, which are described in more detail below. 11 | 12 | * Standups 13 | * Planning 14 | * Reviews/Demos 15 | * Retros 16 | * Backlog Grooming 17 | 18 | ### Standups 19 | 20 | * We’re used to these 21 | * Everyone shares what they’re working on 22 | * Highlight any blockers 23 | * Should be high level, no detail should be discussed during stand ups 24 | * WHY: Get everyone on the same page & show customer daily progress 25 | * WHEN: Once a day 26 | 27 | ### Planning 28 | 29 | * This ceremony should happen at the start of a sprint 30 | * Discuss the user stories (they should be in a prioritised backlog) 31 | * Decide on an approach 32 | * Break them into technical tasks 33 | * We attach points to Trello cards following the (planning poker methodology)[https://www.mountaingoatsoftware.com/agile/planning-poker] 34 | * Decide how much you can do in a sprint 35 | * WHY: Discuss approach, get the team on the same page about technical approach, client is clear on what we expect to do in the upcoming sprint 36 | * WHEN: At the beginning of the sprint 37 | 38 | ### Sprint Review/Demo 39 | 40 | * Go through tasks done in the sprint 41 | * Demo functionality 42 | * WHY: Share progress with stakeholders, get feedback, show off your work 43 | * WHEN: At the end of each sprint 44 | * [See Annise's ToL blog post on Demos](https://dvelp.co.uk/articles/project-demos) 45 | 46 | ### Retros 47 | 48 | * What went well, what could be improved 49 | * Actions 50 | * [Trello template](https://trello.com/b/ZUnzy6bM/retro-template) 51 | * Discuss the retro process itself and whether/how it could be improved 52 | * WHY: Share how you feel, improve this process 53 | * WHEN: At the end of each sprint 54 | * [See Annise's ToL blog post on Retros](https://dvelp.co.uk/articles/retros-for-remote-teams) 55 | 56 | 57 | ### Backlog Grooming 58 | 59 | * Review tickets in the backlog , starting from the bottom (new tickets should be added to the bottom of the board and not moved until grooming) 60 | * Make sure they are relevant and clearly defined 61 | * Is there a clear user story? Is the ticket labelled correctly? 62 | * Agree on their priority - how does it relate to the project goals? 63 | * Highlight any dependencies on the card 64 | * Move the card to the correct position in the backlog based on it’s priority and dependencies 65 | * WHY: Backlogs can get messy, keeping them tidy will make planning easier 66 | * WHEN: At least once a sprint 67 | 68 | ## Additional resources 69 | 70 | * [See the official Scrum.org website article on A typical Sprint Play-by-Play](https://www.scrum.org/resources/blog/typical-sprint-play-play) 71 | * [See Víctor's ToL blog post on Why We Use Agile](https://dvelp.co.uk/articles/why-agile) -------------------------------------------------------------------------------- /guides/project-process/trello.md: -------------------------------------------------------------------------------- 1 | # Trello 2 | A quick guide to using Trello for our projects at DVELP. 3 | 4 | ## So what is it? 5 | A Trello board is a communal, interactive to-do list. Or as Trello puts it - "A list of lists, filled with cards, used by you and your team." 6 | 7 | ## How do we use it at DVELP? 8 | We have a board for each project, with columns for each stage of progression. The life cycle flows from left to right. Each board starts out with a standard set of lists (below), but others can be added depending on the needs of each project. 9 | 10 | ### Each board has 7 lists: 11 | ``` 12 | * Assets 13 | * For Discussion 14 | * To Do 15 | * In Progress 16 | * Code Review 17 | * Client Review 18 | * Done! 19 | ``` 20 | 21 | ## Assets 22 | Create a new item on the board by selecting **Add A New Card**, at the bottom of any column. Find or add the essential elements for the project within the assets column. eg: Links to dropbox for project artwork. 23 | 24 | ## For Discussion 25 | All tasks start their life in this column. Found a bug or potential improvement during your work? Add a card here! If you know the relevant DVELP team mate who can help, click on the card to open a lightbox, and add a member on the right hand side. Here you can also add further comments, a deadline, attach a screen grab, and more. 26 | 27 | ## To Do 28 | The relevant team member decides what needs to be actioned in response to a **For Discussion** card. All is made clear, and the card is dragged into the **To Do** column, and assigned to a suitable team member. 29 | 30 | ## In Progress 31 | Once you have assigned yourself to the **To Do** card and begin the task, move the card to the **In Progress** column to let the team know it is under way. 32 | 33 | ## Code Review 34 | 35 | ### Power-Ups 36 | Trello's Power-Ups allow us to streamline our project boards with other platforms we use. Namely **Slack**, **Harvest**, and **GitHub**. Simply click on a card to open a lightbox, and click the relevant Power-Up button on the right hand side. 37 | 38 | ### GitHub: 39 | Click on a card, navigate to GitHub on the right hand side, and click **Attach Pull Request**. The team can then work on the code seperately from the server. Once you've sent the request, remove yourself as a user. Hover over your avatar in the top left hand side - the members area of the card, then click, and select **Remove From Card**. 40 | 41 | ### Slack: 42 | Use the Slack power-up option to send your Trello card to a channel. Just navigate to **Slack > Send To Channel.** Team members in the Slack conversation will see that there's a card to be checked. The relevant Slack user clicks on the card, and assigns the code review to themselves. Once approved, it gets assigned back to the requesting user. That user then moves card into **Done!** 43 | 44 | ### Harvest: 45 | Report the time spent on an item by clicking on the relevant card and selecting the Harvest power-up. Then select the task you're working on from the drop down list. After that, either start the timer, or record a historic period of time by clicking **My Timesheet**, which will launch Harvest in a new tab. 46 | 47 | -------------------------------------------------------------------------------- /guides/ruby-gems/Creating Ruby Gems bespoke for DVELP.md: -------------------------------------------------------------------------------- 1 | # Creating Ruby Gems bespoke for DVELP 2 | 3 | ## Prerequisites 4 | 5 | 1. Configure bundler: 6 | 7 | `bundle config gem.test rspec` 8 | 9 | * Other popular config options include: 10 | 11 | `bundle config build.nokogiri --use-system-libraries` 12 | 13 | `bundle config gem.coc true` (adds Code of Conduct.md) 14 | 15 | `bundle config gem.mit true` (adds MIT License to License.txt) 16 | 17 | ## Setup 18 | 19 | 1. Create the gem scaffold: 20 | 21 | `bundle gem ${gem_name}` 22 | 23 | 1. Gitignore `Gemfile.lock` if it hasn't already been ignored. [2] 24 | 25 | 2. Update `${gem_name}.gemspec` 26 | 27 | 3. Add CLI if needed (with install command): [5] 28 | 29 | * Add `spec.add_dependency 'thor'` to `${gem_name}.gemspec` & `bundle install` 30 | 31 | ``` 32 | cd ${gem_name} 33 | mkdir -p lib/${gem_name}/cli/install_files 34 | mkdir exe 35 | module_name=`echo ${gem_name:0:1} | tr '[a-z]' '[A-Z]'`${gem_name:1} 36 | 37 | cat < lib/${gem_name}/cli/install.rb 38 | require 'thor/group' 39 | 40 | module ${module_name} 41 | class CLI < Thor 42 | class Install < Thor::Group 43 | include Thor::Actions 44 | 45 | def self.start 46 | source_root = File.expand_path('../install_files', __FILE__) 47 | FileUtils.cp_r "#{source_root}/.", Dir.pwd 48 | end 49 | end 50 | end 51 | end 52 | EOT 53 | 54 | cat < lib/${gem_name}/cli.rb 55 | require 'thor' 56 | 57 | module ${module_name} 58 | class CLI < Thor 59 | # ${gem_name} install 60 | 61 | desc 'install', 'Install ${module_name}' 62 | def install 63 | # make require here to hide it from Thor CLI actions 64 | require '${gem_name}/cli/install' 65 | Install.start 66 | end 67 | end 68 | end 69 | EOT 70 | 71 | cat < exe/${gem_name} 72 | #!/usr/bin/env ruby 73 | 74 | require '${gem_name}/cli' 75 | 76 | ${module_name}::CLI.start 77 | EOT 78 | 79 | chmod +x exe/${gem_name} 80 | 81 | ``` 82 | 83 | * Add any files you want copied on install action to `lib/${gem_name}/cli/install_files` 84 | * Keep in mind that when you install gem with `rake install`, you need to reload shell to be able to execute the CLI commands 85 | 86 | ## Usefull commands 87 | 88 | * `bundle install` - install dependency gems 89 | * `rake install` - install the gem; requires changes to be committed! 90 | * `bundle console` - similar to rails console 91 | * `bundle exec ${file_name}` - runs the script with the current gem environment 92 | 93 | ## Remarks 94 | 95 | All gem specific code should go in `lib/${gem_name}` and be nested inside `module ${module_name}`. This prevents name collisions as module acts as namespace. 96 | 97 | ## Sources 98 | 99 | 1. [$ bundle help](http://bundler.io/v1.10/man/bundle.1.html) 100 | * [Why gitignore Gemfile.lock](http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/) 101 | * [Gem development](https://github.com/radar/guides/blob/master/gem-development.md) 102 | * [Figaro gem example](https://github.com/laserlemon/figaro) 103 | * [Thor](http://whatisthor.com/) 104 | 105 | ***** 106 | 107 | * 108 | ###### Note that you can set shell variables like this `gem_name="nelly"`, and run most of the commands without having to change anything. Here's the list of variables needed: 109 | 110 | ``` 111 | gem_name="" 112 | ``` 113 | -------------------------------------------------------------------------------- /guides/ruby-gems/README.md: -------------------------------------------------------------------------------- 1 | # DVELP Gems 2 | 3 | The following are some quick guides to common tasks we encounter when working 4 | with gems at DVELP: 5 | 6 | * [Creating Gems](Creating%20Ruby%20Gems%20bespoke%20for%20DVELP.md) 7 | * [Installing Private Gems](installing-private-gems.md) 8 | -------------------------------------------------------------------------------- /guides/ruby-gems/gemfury.md: -------------------------------------------------------------------------------- 1 | # Gemfury Usage 2 | 3 | Gemfury is a private gem server that we use to easily manage access to private gems. 4 | 5 | ## Publishing a Gem 6 | 7 | To publish new gem or new version of the gem you need to follow the steps below: 8 | 9 | - Install gemfury gem: `gem install gemfury` 10 | - Authenticate with your Gemfury login credentials: `fury login` 11 | - Build the gem: `gem build .gemspec` 12 | - Upload your package: `fury push -.gem --as=dvelp` 13 | 14 | That’s it! 15 | 16 | ### Publishing via Cicrle CI 17 | 18 | To have the gem automatically published when a new version is created, add the following to your `circle.yml` file: 19 | 20 | ``` 21 | - run: 22 | name: Publish gem to gemfury 23 | command: | 24 | if [ "${CIRCLE_BRANCH}" == "master" ] 25 | then 26 | gem install gemfury 27 | gem build .gemspec 28 | fury push $(ls | grep -) --as=dvelp --api-token=$BUNDLE_GEM__FURY__IO 29 | else 30 | echo "Publishing to gemfury allowed only for master branch" 31 | fi 32 | ``` 33 | 34 | ## Installing a Gem 35 | 36 | To install a gem from gemfury you need to follow the steps below: 37 | 38 | - Copy your personal access token from [here](https://manage.fury.io/manage/dvelp/tokens). 39 | - Configure your bundler: `bundle config gem.fury.io ` 40 | - For builds and deployment, you may configure authentication through the environment: `export BUNDLE_GEM__FURY__IO=` 41 | - Add new source to your Gemfile: `source 'https://gem.fury.io/dvelp'` 42 | - Bundle! 43 | 44 | ### Configure Authentication on CircleCI and Heroku 45 | 46 | To allow Circle CI and Heroku to install gems from gemfury you simple need to set your auth token to new environment variable: `BUNDLE_GEM__FURY__IO: ` 47 | 48 | ## Other Links 49 | 50 | For more information visit https://gemfury.com/help/getting-started 51 | -------------------------------------------------------------------------------- /guides/ruby-gems/installing-private-gems.md: -------------------------------------------------------------------------------- 1 | # Installing Private Gems 2 | 3 | At DVELP, we have a number of gems (private repos) that we use internally. The 4 | following is a brief guide on how to install them both locally and on Heroku. 5 | 6 | ## Fetch a GitHub Oauth Token 7 | 8 | To authenticate Bundler on GitHub, you will need an OAuth token. GitHub have a 9 | nice [guide](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) on how to do this. 10 | 11 | ## Set up Your Credentials 12 | 13 | To install the credentials for your current project (dir): 14 | 15 | ``` 16 | bundle config GITHUB__COM myoauthtoken:x-oauth-basic 17 | ``` 18 | 19 | Or, if you want to install the credentials globally: 20 | 21 | ``` 22 | $ bundle config --local GITHUB__COM myoauthtoken:x-oauth-basic 23 | ``` 24 | 25 | ## Add to Your Gemfile 26 | 27 | Add your private repo the application Gemfile: 28 | 29 | ``` 30 | gem 'dvelp_gem', git: 'https://github.com/DVELP/dvelp_gem.git' 31 | ``` 32 | 33 | Then run `bundle install` and you are good to go! 34 | 35 | 36 | ## Installing on Heroku 37 | 38 | Installing private gems on Heroku is fairly straightfoward. Make sure you have 39 | your OAuth token, then run the following command: 40 | 41 | ``` 42 | heroku config:add BUNDLE_GITHUB__COM=myoauthtoken:x-oauth-basic --app my-app 43 | ``` 44 | 45 | Next time you deploy the application, the private gem will be installed when 46 | bundler runs. 47 | 48 | -------------------------------------------------------------------------------- /guides/tools/README.md: -------------------------------------------------------------------------------- 1 | # Tools 2 | 3 | The following are some quick guides to common tools we use at DVELP on a day-to-day basis: 4 | 5 | * [ngrok](ngrok.md) 6 | * [s3-bucket](s3-bucket.md) 7 | * [zoiper-soft-phone](zoiper-soft-phone.md) 8 | * [live code sharing for pair programming](live-code-share.md) 9 | -------------------------------------------------------------------------------- /guides/tools/live-code-share.md: -------------------------------------------------------------------------------- 1 | # Live Code Sharing 2 | 3 | During the 4 hour pair programming interview we may need a tool to share code from a specific workspace or perhaps have a programming session with one of our teammates. From all the different approaches out there, at DVELP we propose the following: 4 | 5 | ## Getting Started 6 | 7 | 1. Install [Visual Studio Code](https://code.visualstudio.com), if not installed. 8 | 2. Install [Live Share Extension Pack](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-pack) 9 | 3. Restart Visual Studio Code app 10 | 4. Sign in with your GitHub account. To do that press `command+shift+P` for Mac or `control+shift+P` for Windows/Linux machines and type "Live Share: Sign In With Browser" -> "Sign in with GitHub" 11 | 12 | ![Live Code Share](../../assets/live-code-share-1.png) 13 | 14 | 5. Follow "Authorize Visual Studio Live Share" steps in your browser to continue singing in process 15 | 6. After this you should be able to start a live session. To do that, click on the relevant icon of "Live Share" extension on your activity bar 16 | 17 | ![Live Code Share](../../assets/live-code-share-2.png) 18 | 19 | 7. Now, you can start your live session simply by clicking on "Start collaboration session...". It should also copy an invitation link to your clipboard automatically, so you can share it with your peer 20 | 8. To stop your live session click on stop icon on "Session Details" panel 21 | 22 | ![Live Code Share](../../assets/live-code-share-3.png) 23 | 24 | ## Other Links 25 | 26 | For more information visit [the official web-site](https://visualstudio.microsoft.com/services/live-share) of the extension. 27 | -------------------------------------------------------------------------------- /guides/tools/ngrok.md: -------------------------------------------------------------------------------- 1 | # Tunnel to localhost 2 | Ngrok allows you to expose a web server running on your local machine to the internet. It's very handy for developing APIs, in particular when working with Twilio. 3 | 4 | 5 | ## Install 6 | 7 | Follow the quickstart guide [here](https://ngrok.com/download). 8 | 9 | ## Run Your Server 10 | 11 | First fire up your application, with rails it would look like this: 12 | 13 | ``` 14 | rails server 3000 15 | ``` 16 | 17 | N.B. You will need the port number to instruct ngrok 18 | 19 | 20 | ## Tunnel In 21 | 22 | Once your server is running, all that's left is to expose the port to the internet with ngrok: 23 | 24 | ``` 25 | ngrok http 3000 26 | ``` 27 | 28 | Where `http` is the protocol and `3000` is the port number. Ngrok will display a UI in your terminal with the public URL of your tunnel and other connection information. 29 | 30 | 31 | ## Inspecting your Traffic 32 | Ngrok provides a real-time web UI where you can introspect all traffic running over your tunnels. After you've started ngrok, just open http://localhost:4040 in a web browser to inspect request details. 33 | 34 | 35 | ## Advanced Configuration 36 | There are plenty more configuration options, including custom domain names etc. For more details, you can check the ngrok docs https://ngrok.com/docs 37 | -------------------------------------------------------------------------------- /guides/tools/s3-bucket.md: -------------------------------------------------------------------------------- 1 | # Create a new S3 bucket 2 | 3 | If you need to create a S3 bucket, you should use our template bucket as the image, to ensure our default properties are applied to it. 4 | 5 | ## DVELP image bucket 6 | 7 | We have created a bucket that we will use as the image to create any new bucket. 8 | This bucket name is `dvelp-bucket-template` and has these properties: 9 | - Restricted Public access 10 | - Enabled Logs and storaged in our bucket for logs (`dvelp-logs`) 11 | - It’s encrypted using Amazon AES-256 encryption. 12 | 13 | ## How to create a new bucket using the bucket image 14 | 15 | [Go to S3 buckets](https://s3.console.aws.amazon.com) and choose Create a new bucket. 16 | - Select `Copy settings from an existing bucket` 17 | - Search the template bucket `dvelp-bucket-template` 18 | - Click Create. No need to go through the next steps, all the properties inherits from the bucket template. 19 | 20 | That’s it!. Your new bucket inherits the properties of dvelp-bucket-template. 21 | 22 | If you need to configure any other properties, check the AmazonS3 documentation: [create new bucket](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html) 23 | 24 | ## Ownership 25 | 26 | Víctor Alejo is the owner of this document. You can contact him on 27 | . 28 | -------------------------------------------------------------------------------- /guides/tools/zoiper-soft-phone.md: -------------------------------------------------------------------------------- 1 | # Zoiper Soft-phone 2 | 3 | Soft-phones allow you to make and receive phone calls over the Internet using your computer rather than dedicated hardware. Soft-phones are great for manual testing of Twilio apps. There are lot clients to choose from, but this doc will explain how to configure Zoiper. 4 | 5 | ## Download 6 | 7 | To download Zoiper visit https://www.zoiper.com. 8 | 9 | ## Sip Domain 10 | 11 | Before you configure the Zoiper client you have to create SIP domain on [Twilio ](https://www.twilio.com/console/voice/sip/endpoints/add). Fill in following fields: 12 | - FRIENDLY NAME - preferably your name 13 | - SIP URI - URI which you will need to use for Zoiper configuration later 14 | - REQUEST URL - URL to your application which will handle API requests (see [how to configure ngrok](https://github.com/DVELP/cookbook/blob/master/guides/tools/ngrok.md) to get public url from your localhost) 15 | - SIP Registration should be set to ENABLED 16 | 17 | ### Authentication 18 | 19 | Soft-phones require basic authentication, so we have to create a user and password. On Twilio: 20 | - Click on `+` next to the CREDENTIAL LISTS field or go to [Credential Lists](https://www.twilio.com/console/voice/sip/cls) directly. 21 | - Fill in the form: 22 | - FRIENDLY NAME - preferably your name 23 | - USERNAME - enter your phone number in E164 format e.g. +441231231231 24 | - PASSWORD - your password (don't forget to use 1Password) 25 | - Once it's done click on create. You should see a new record in the CREDENTIAL LISTS field 26 | - Select newly created credential within SIP Registration Authentication block 27 | - Save your SIP domain 28 | 29 | ## Zoiper Configuration 30 | 31 | After installing Zoiper you will be requested to enter the following credentials: 32 | 1. Fill user name (phone number) and password which we created before. 33 | 2. Fill in your localized hostname, you can find it on [Voice SIP Domains](https://www.twilio.com/console/voice/sip/endpoints) page, e.g. `dvelp-test.sip.us1.twilio.com` 34 | 3. Skip Authentication and outbound proxy 35 | 4. Skip testing step 36 | 5. Click Create Account 37 | 38 | In order to receive incoming calls, use this TwiML Bin example to redirect one of your phone numbers to your SIP client: 39 | 40 | ```xml 41 | 42 | 43 | 44 | +441231231231@dvelp-test.sip.us1.twilio.com 45 | 46 | 47 | 48 | ``` 49 | 50 | Where `+441231231231` is your USERNAME and `dvelp-test.sip.us1.twilio.com` is your SIP URI. 51 | 52 | That's it. Now you are ready to make and receive calls! 53 | 54 | ## Other Links 55 | 56 | For more information visit https://www.twilio.com/blog/registering-sip-phone-twilio-inbound-outbound 57 | -------------------------------------------------------------------------------- /guides/twilio/twilio-number-porting-timeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sabio-engineering/cookbook-dvelp/386811e160a7018beb9276430033c78e2e0ef5d0/guides/twilio/twilio-number-porting-timeline.png -------------------------------------------------------------------------------- /handbook/best-practice/anti-harassment.md: -------------------------------------------------------------------------------- 1 | ## Anti-harassment and Bullying Policy 2 | 3 | The purpose of this policy is to ensure that all staff are treated and treat others with dignity and respect, free from harassment and bullying. All staff should take the time to ensure they understand what types of behaviour are unacceptable under this policy. 4 | 5 | This policy covers harassment or bullying which occurs both in and out of the workplace, such as on business trips or at events or work-related social functions. It covers bullying and harassment by staff and also by third parties such as customers, suppliers or visitors to our premises. 6 | 7 | Staff must treat colleagues and others with dignity and respect, and should always consider whether their words or conduct could be offensive. Even unintentional harassment or bullying is unacceptable. 8 | 9 | We will take allegations of harassment or bullying seriously and address them promptly and confidentially where possible. Harassment or bullying by an employee will be treated as misconduct under our Disciplinary Procedure. In some cases it may amount to gross misconduct leading to summary dismissal. 10 | 11 | #### What is harassment? 12 | 13 | Harassment is any unwanted physical, verbal or non-verbal conduct which has the purpose or effect of violating a person's dignity or creating an intimidating, hostile, degrading, humiliating or offensive environment for them. A single incident can amount to harassment. 14 | 15 | It also includes treating someone less favourably because they have submitted or refused to submit to such behaviour in the past. 16 | 17 | Unlawful harassment may involve conduct of a sexual nature (sexual harassment), or it may be related to age, disability, gender reassignment, marital or civil partner status, pregnancy or maternity, race, colour, nationality, ethnic or national origin, religion or belief, sex or sexual orientation. Harassment is unacceptable even if it does not fall within any of these categories. 18 | 19 | #### What is bullying? 20 | 21 | Bullying is offensive, intimidating, malicious or insulting behaviour involving the misuse of power that can make a person feel vulnerable, upset, humiliated, undermined or threatened. Power does not always mean being in a position of authority, but can include both personal strength and the power to coerce through fear or intimidation. 22 | 23 | **Initial steps** 24 | 25 | If you are being bullied or harassed, you should initially consider raising the problem informally with the person responsible, if you feel able. You should explain clearly to them that their behaviour is not welcome or makes you uncomfortable. If this is too difficult or embarrassing, you should speak to the Board of Directors, who can provide confidential advice and assistance in resolving the issue formally or informally. 26 | 27 | -------------------------------------------------------------------------------- /handbook/best-practice/whistle-blowing-policy.md: -------------------------------------------------------------------------------- 1 | ## Whistleblowing Policy 2 | 3 | #### About this policy 4 | 5 | We are committed to conducting our business with honesty and integrity and we expect all staff to maintain high standards. We encourage staff to report suspected wrongdoing as soon as possible. 6 | 7 | #### Who is covered by this policy? 8 | 9 | This policy applies to all individuals working at all levels of the organisation, including senior managers, officers, directors, employees, consultants, contractors, trainees, homeworkers, part-time and fixed-term workers, casual and agency staff (collectively referred to as "staff" in this policy). 10 | 11 | #### What is whistleblowing? 12 | 13 | Whistleblowing is the reporting of suspected wrongdoing or dangers in relation to our activities. This includes bribery, fraud or other criminal activity, miscarriages of justice, health and safety risks, damage to the environment and any breach of legal or professional obligations. 14 | 15 | #### How to raise a concern 16 | 17 | We hope that in many cases you will be able to raise any concerns with your manager. However, where you prefer not to raise it with your manager for any reason, you should contact the Board of Directors. 18 | 19 | We will arrange a meeting with you as soon as possible to discuss your concern. You may bring a colleague or union representative to any meetings under this policy. Your companion must respect the confidentiality of your disclosure and any subsequent investigation. 20 | 21 | #### Confidentiality 22 | 23 | We hope that staff will feel able to voice whistleblowing concerns openly under this policy. Completely anonymous disclosures are difficult to investigate. If you want to raise your concern confidentially, we will make every effort to keep your identity secret and only reveal it where necessary to those involved in investigating your concern. 24 | 25 | #### External disclosures 26 | 27 | The aim of this policy is to provide an internal mechanism for reporting, investigating and remedying any wrongdoing in the workplace. In most cases you should not find it necessary to alert anyone externally. 28 | 29 | The law recognises that in some circumstances it may be appropriate for you to report your concerns to an external body such as a regulator. We strongly encourage you to seek advice before reporting a concern to anyone external. Public Concern at Work operates a confidential helpline. Their contact details are at the end of this policy. 30 | 31 | #### Protection and support for whistleblowers 32 | 33 | We aim to encourage openness and will support staff who raise genuine concerns in good faith under this policy, even if they turn out to be mistaken. 34 | 35 | Staff must not suffer any detrimental treatment as a result of raising a concern in good faith. If you believe that you have suffered any such treatment, you should inform the Managing Director immediately. 36 | 37 | Staff must not threaten or retaliate against whistleblowers in any way. Anyone involved in such conduct will be subject to disciplinary action. 38 | 39 | If we conclude that a whistleblower has made false allegations maliciously, in bad faith or with a view to personal gain, the whistleblower may be subject to disciplinary action. 40 | 41 | Public Concern at Work operates a confidential helpline. Their contact details are at the end of this policy. 42 | 43 | #### Contacts 44 | 45 | You can find our independent whistleblowing contact's contact details [here](../README.md#contacts) 46 | 47 | -------------------------------------------------------------------------------- /handbook/hr/compassionate-leave.md: -------------------------------------------------------------------------------- 1 | ## Compassionate Leave 2 | 3 | Compassionate leave is designed to help an employee where they need to deal with necessary arrangements for or assist a close relative who is seriously or critically ill. 4 | 5 | #### Entitlement 6 | 7 | Staff are entitled to take compassionate leave of up to 7 days in any 12-month period in respect of a spouse or partner, child, stepchild, grandchild, parent, step-parent, parent-in-law, grandparent, brother or sister, stepbrother or stepsister, or brother or sister-in-law. 8 | 9 | We may exercise our discretion to grant compassionate leave in respect of any other relative or close friend, depending on the circumstances of each case. 10 | 11 | An employee who is unable to return to work following a period of compassionate leave should contact their line manager. It may be appropriate to take a period of annual leave or unpaid leave in those circumstances. 12 | 13 | #### Requesting compassionate leave 14 | 15 | We recognise that it may not always be possible to request compassionate leave in advance. However, where it is possible, you should make a request to your manager. You should tell them the reasons for your request and the number of days leave you would like to take. 16 | 17 | Where it is not possible to request leave in advance you should contact your manager as soon as possible to tell them the reason for your absence and the number of days you expect to be absent. Someone can do this on your behalf if necessary. 18 | 19 | In exceptional circumstances we may have to refuse a request for compassionate leave. If so your manager will give you a written explanation for the refusal. 20 | 21 | -------------------------------------------------------------------------------- /handbook/hr/dress-code.md: -------------------------------------------------------------------------------- 1 | ## Dress Code 2 | 3 | We encourage everyone to maintain an appropriate standard of dress and personal appearance at work and to conduct her or himself in a professional manner. The purpose of our dress code is to establish basic guidelines on appropriate clothing and appearance at our workplace, so that we: 4 | 5 | 1. promote a positive image and staff look professional; 6 | 2. respect religious, racial and gender-specific clothing requirements and those of staff with disabilities where possible; 7 | 3. take account of health and safety requirements; and 8 | 4. help staff decide what clothing it is appropriate to wear to work. 9 | 10 | We expect staff to take a common sense approach to the dress code. -------------------------------------------------------------------------------- /handbook/hr/equal-opportunities.md: -------------------------------------------------------------------------------- 1 | ## Equal Opportunities Policy 2 | 3 | We are committed to promoting equality of opportunity for all staff and job applicants. We aim to create a working environment in which all individuals are able to make best use of their skills, free from discrimination or harassment, and in which all decisions are based on merit. 4 | 5 | We do not discriminate against staff on the basis of age, disability, gender reassignment, marital or civil partner status, pregnancy or maternity, race, colour, nationality, ethnic or national origin, religion or belief, sex or sexual orientation ( **"protected characteristics"** ). 6 | 7 | The principles of non-discrimination and equality of opportunity also apply to the way in which staff treat visitors, clients, customers, suppliers and former staff members. 8 | 9 | All staff have a duty to act in accordance with this policy and treat colleagues with dignity at all times, and not to discriminate against or harass other members of staff, regardless of their status. 10 | 11 | #### Breaches of the policy 12 | 13 | If you believe that you may have been discriminated against you are encouraged to raise the matter through our [Grievance Procedure](grievance-procedure.md). If you believe that you may have been subject to harassment you are encouraged to raise the matter through our [Anti-harassment and Bullying Policy](../best-practice/anti-harassment.md). If you are uncertain which applies or need advice on how to proceed you should speak to the CEO. 14 | 15 | -------------------------------------------------------------------------------- /handbook/hr/expenses-policy.md: -------------------------------------------------------------------------------- 1 | ## Expenses Policy 2 | 3 | ### Reimbursement of expenses 4 | 5 | We will reimburse expenses properly incurred in accordance with this policy. Any attempt to claim expenses in breach of this policy may result in disciplinary action. 6 | 7 | Expenses will only be reimbursed if they are: 8 | 9 | 1. approved by Ruby __before__ they are incurred; 10 | 2. claimed using the [DVELP Expenses Platform](https://dvelp-expenses.firebaseapp.com/expenses); 11 | 3. submitted within 2 months of being incurred; 12 | 4. supported by relevant documents (for example, VAT receipts, tickets, and credit or debit card slips); and 13 | 14 | Claims for authorised expenses submitted in accordance with this policy will be paid directly into your bank/building society account. 15 | 16 | Any questions about the reimbursement of expenses should be put to your manager before you incur the relevant costs. 17 | 18 | #### Travel expenses 19 | 20 | We will reimburse the reasonable cost of necessary travel in connection with our business. The most economic means of travel should be chosen if practicable/possible and you should use existing travelcards and season tickets wherever possible. The following are not treated as travel in connection with our business: 21 | 22 | 1. travel between your home and usual place of work; 23 | 2. travel which is mainly for your own purposes; and 24 | 3. travel which, while undertaken on our behalf, is similar or equivalent to travel between your home and your usual place of work. 25 | 26 | Please contact your manager regarding specific transport queries. 27 | 28 | ### Submitting expenses 29 | 30 | Expenses can be submitted using the [DVELP Expenses Platform](https://dvelp-expenses.firebaseapp.com/expenses). 31 | 32 | Following submission they will be reviewed by management. If an expense is approved, it will be paid into your bank account. If an expense is not approved, your manager will discuss the expense with you. 33 | -------------------------------------------------------------------------------- /handbook/hr/grievance-procedure.md: -------------------------------------------------------------------------------- 1 | ## Grievance Procedure 2 | 3 | #### Who is covered by the procedure? 4 | 5 | This procedure applies to all staff regardless of length of service. However, it does not form part of your contract. It may be amended at any time and we may depart from it depending on the circumstances of any case. 6 | 7 | #### Using the grievance procedure 8 | 9 | Most grievances can be resolved quickly and informally through discussion with your line manager. If this does not resolve the problem you should initiate the formal procedure below reasonably promptly. 10 | 11 | #### Step 1: written grievance 12 | 13 | You should put your grievance in writing and submit it to your line manager. If your grievance concerns your line manager you may submit it to the Board of Directors. 14 | 15 | The written grievance should set out the nature of the complaint, including any relevant facts, dates, and names of individuals involved so that we can investigate it. 16 | 17 | #### Step 2: meeting 18 | 19 | We will arrange a grievance meeting, normally within one week of receiving your written grievance. You should make every effort to attend. 20 | 21 | You may bring a companion to the grievance meeting if you make a reasonable request in advance and tell us the name of your chosen companion. The companion may be either a trade union representative or a colleague, who will be allowed reasonable paid time off from duties to act as your companion. 22 | 23 | If you or your companion cannot attend at the time specified you should let us know as soon as possible and we will try, within reason, to agree an alternative time. 24 | 25 | We may adjourn the meeting if we need to carry out further investigations, after which the meeting will usually be reconvened. 26 | 27 | We will write to you, usually within one week of the last grievance meeting, to confirm our decision and notify you of any further action that we intend to take to resolve the grievance. We will also advise you of your right of appeal. 28 | 29 | #### Step 3: appeals 30 | 31 | If the grievance has not been resolved to your satisfaction you may appeal in writing to the Board of Directors stating your full grounds of appeal, within one week of the date on which the decision was sent or given to you. 32 | 33 | We will hold an appeal meeting, normally within 2 weeks of receiving the appeal. This will be dealt with impartially by a manager who has not previously been involved in the case. You will have a right to bring a companion (see Paragraph ). 34 | 35 | We will confirm our final decision in writing, usually within one week of the appeal hearing. There is no further right of appeal. 36 | -------------------------------------------------------------------------------- /handbook/hr/off-boarding.md: -------------------------------------------------------------------------------- 1 | # Off-boarding 2 | 3 | When an member of our team leaves we conduct we complete an off-boarding 4 | process. 5 | 6 | This process is defined in a CharlieHR checklist which can be found 7 | [here](https://dvelp.charliehr.com/checklist_templates/4840). 8 | 9 | It is the joint responsibility of the individual's Line Manager and the [HR 10 | Manager](../README.md#contacts) to ensure the off-boarding 11 | checklist is completed. 12 | -------------------------------------------------------------------------------- /handbook/hr/on-boarding.md: -------------------------------------------------------------------------------- 1 | # On-boarding 2 | 3 | When someone joins our team, we complete an on-boarding process. 4 | 5 | This process is defined in a CharlieHR checklist template which can be found 6 | [here](https://dvelp.charliehr.com/checklist_templates). 7 | 8 | It is the joint responsibility of the individual's Line Manager and the [HR 9 | Manager](../README.md#contacts) to ensure the on-boarding 10 | checklist is completed within one month of the new team member joining. 11 | 12 | # On-boarding advice from our team 13 | 14 | Welcome to DVELP. In this article our team have summarised their advice for new 15 | joiners on their on-boarding journey. 16 | 17 | ## Company culture information 18 | 19 | Overall information about cultural processes like meetings, time managment, 20 | communication is explained in [this quick reference 21 | guide](/handbook/quick-reference.md). We recomend you read this before anything 22 | else. 23 | 24 | ## Acquaintance with your mentor 25 | 26 | Your mentor is your best friend during the process of on-boarding. He can help 27 | you with solving any questions. It would be good if you can make a video call 28 | with your mentor and receive an **on-boarding session**. Details of 29 | communication between mentee and mentor are described 30 | [here](/handbook/professional-development/mentoring.md). 31 | 32 | After you have had your on-boarding session with your mentor, it will be very 33 | useful if you could arrange a 5min call with all team members to introduce 34 | yourself and let them introduce themselves to you. 35 | 36 | ## Technical articles: 37 | 38 | Over the years we made a collection of our own style guides, recomendations and 39 | process explanations. We continually contribute to them and follow them to make 40 | all of our projects consistent. 41 | 42 | ### GIT 43 | 44 | We have a [quick guide](/guides/code-management/git.md) of how we working with 45 | GIT and GitHub. 46 | 47 | ### Style guides 48 | 49 | You can find our code style guides in [this folder](/guides/code-style). Both 50 | for Front End and Back End. 51 | 52 | ### Configuring lints 53 | 54 | We are using a number of linters to keep our code clean and consistent. 55 | [Here](/guides/code-style/Readme.md) you can find our configurations and a way 56 | to setup it. 57 | 58 | ### Twilio Quest 59 | 60 | Most likely, at some point, you will be involved to project that use Twilio. So 61 | it's strongly recommended to go through [Twilio 62 | Quest](https://www.twilio.com/quest/welcome). Before you start it, you will need 63 | to contact your mentor to allow him to create an account for you. 64 | 65 | ## Cookbook 66 | 67 | There is much more in our Cookbook, which will be useful in different 68 | situations. Please feel free to explore it! A good place to start can be [table 69 | of contents](/Readme.md). 70 | 71 | ## Handbook 72 | 73 | The [DVELP Handbook](/handbook/README.md) contains our company's policies that 74 | define how we think about things like best practice, professional development 75 | and information security. It is a good place to reference for specific 76 | quesitons. 77 | 78 | ## Useful links 79 | 80 | - [System admins](/handbook/information-security/access-control.md) - Is a place where 81 | you can find a system admin and his deputy for some exact platform. Can be 82 | useful when you need to get access to some system. 83 | - [Our blog](https://dvelp.co.uk/articles) - This contains a lot of articles 84 | that explain our approach and expertise in everything we do. 85 | -------------------------------------------------------------------------------- /handbook/hr/org-chart.md: -------------------------------------------------------------------------------- 1 | # DVELP Org Chart 2 | 3 | ![Org Chart](../../assets/DVELP-org-chart.png) 4 | -------------------------------------------------------------------------------- /handbook/hr/personal-details.md: -------------------------------------------------------------------------------- 1 | ## Personal details, home address and next of kin 2 | 3 | The Board of Directors is responsible for maintaining up-to-date details of the home address, next of kin and emergency contact telephone numbers of each member of our staff. 4 | 5 | This information will be requested by the Board of Directors when you start work and you should advise of any changes straight away. 6 | 7 | It is important that we maintain accurate details in case a member of staff has an accident. Information is held in confidence and is only used when needed. 8 | 9 | -------------------------------------------------------------------------------- /handbook/hr/redundancy-policy.md: -------------------------------------------------------------------------------- 1 | ## Redundancy Policy 2 | 3 | It is our intention to manage our business in a manner, which results in secure employment for our employees. We will always try to avoid the need for compulsory redundancies but sometimes these may be necessary. The pattern or volume of our business or methods of working may change and requirements for employees may reduce. 4 | 5 | #### The purpose of the policy 6 | 7 | The purpose of this policy is to ensure that, whenever reduction in employee numbers may become necessary: 8 | 9 | 1. we communicate clearly with all affected employees and ensure that they are treated fairly; 10 | 2. we try to find ways of avoiding compulsory redundancies; 11 | 3. we consult with employees and with recognised trade unions **or** employee representatives; and 12 | 4. any selection for compulsory redundancy is undertaken fairly and reasonably. 13 | 14 | #### Avoiding compulsory redundancies 15 | 16 | Where we are proposing to make redundancies we will enter into consultation with all affected employees on an individual basis and, where appropriate, also with recognised trade unions _or_ employee representatives. 17 | 18 | In the first instance we will consider steps that might, depending on the circumstances, be taken to avoid the need for compulsory redundancies. Examples of such steps include: 19 | 20 | 1. reviewing the use of agency staff, self-employed contractors and consultants; 21 | 2. restricting recruitment in affected categories of employee and in those areas into which affected employees might be redeployed; 22 | 3. reducing overtime in affected departments to that needed to meet contractual commitments or provide essential services; 23 | 4. freezing salaries for a specified period; 24 | 5. considering the introduction of short-time working, job-sharing or other flexible working arrangements, where these are practicable; 25 | 6. identifying suitable alternative work that might be offered to potentially redundant employees. 26 | 7. inviting applications for early retirement or voluntary redundancy. In all cases the acceptance of a volunteer for redundancy will be a matter of our discretion and we reserve the right not to offer voluntary redundancy terms or to refuse an application where it is not in the interests of our business to do so. 27 | 28 | Any measures adopted must not adversely affect our business and our ability to serve our customers. 29 | 30 | #### Making compulsory redundancies 31 | 32 | When it is not possible to avoid making compulsory redundancies, all affected employees and, where appropriate, recognised trade unions **or** employee representatives will be advised that compulsory redundancies cannot be avoided. They will be consulted on the procedure that will then be followed and the criteria that will be applied. 33 | 34 | The criteria used to select those employees who will potentially be made redundant will be objective, transparent and fair and based on the skills required to meet our existing and anticipated business needs. 35 | 36 | Those employees who have been provisionally selected for redundancy will be consulted with individually. 37 | 38 | Where selection for redundancy is confirmed, employees selected for redundancy will be given notice of termination of employment in accordance with their contracts and written confirmation of the payments that they will receive. 39 | 40 | We will continue to look for alternative employment for redundant employees and inform them of any vacancies that we have until their termination dates. The manner in which redundant employees will be invited to apply for and be interviewed for vacancies will be organised depending on the circumstances existing at the time. Alternative employment may be offered subject to a trial period where appropriate. 41 | -------------------------------------------------------------------------------- /handbook/hr/referral-programme.md: -------------------------------------------------------------------------------- 1 | # Referral Programme 2 | 3 | We run a candidate referral program at DVELP. If you recommend a candidate for a role we 4 | are looking to fill and that candidate gets hired and passes his/her probation 5 | period, you will will receive an extra £500 in your next pay cheque. 6 | 7 | To manage this process, we are using Greenhouse.io, our Applicant Tracking 8 | System: 9 | 10 | 1. Log into [Greenhouse.io](https://www.greenhouse.io/login) 11 | 2. Go to "All Jobs" to see the jobs for which you can submit candidates 12 | 3. Select a job 13 | 4. Go to "Candidates" 14 | 5. Click "+ Add Candidate" 15 | 6. Make sure you mark yourself as the "Source" 16 | 17 | If the candidate is hired and passes his probation, the payment will be 18 | triggered. 19 | 20 | If you have any questions regarding this process, please get in touch with the 21 | [HR Manager](../README.md#contacts). 22 | -------------------------------------------------------------------------------- /handbook/hr/retirement-policy.md: -------------------------------------------------------------------------------- 1 | ## Retirement Policy (no fixed retirement age) 2 | 3 | We currently have no fixed retirement age although this will be reviewed from time to time by our Board of Directors to reflect our business needs. We acknowledge that retirement is a matter of choice for individuals and will not pressurise staff into resigning because they have reached or are approaching a certain age. 4 | 5 | Staff are free to retire whenever they choose or to seek alternative working patterns. For further information, see our Flexible Working Policy. 6 | 7 | We are proud to employ people of all ages and consider that age diversity is beneficial to the organisation. We are committed to not discriminating against staff because of age and adhere to the principles set out in our [Equal Opportunities Policy](equal-opportunities.md). 8 | 9 | #### The purpose of the policy 10 | 11 | This policy aims to create a framework for workplace discussions, enabling you to express your preferences and expectations with regard to retirement and enabling us to plan for our business. 12 | 13 | #### Discussing your future plans 14 | 15 | You or your manager may want to discuss your short, medium and long-term plans, as the need arises. For example, a promotion opportunity may arise, or, if your circumstances change, you may want a different working pattern or to stop work altogether. We need to plan for the business, and so may indicate to staff from time to time that it would be helpful to know what their plans are. There is no obligation for us or you to hold workplace discussions about your future plans, but it may be mutually beneficial to do so. 16 | 17 | We will not make generalised assumptions that performance will decline with age, whether due to competence or health issues. If we think there are problems with your performance or ill-health, these will be dealt with in the usual way, through the Capability Procedure or [Sickness Absence Policy](absence.md). 18 | 19 | If a workplace discussion takes place for the purposes described above, we will aim to make it as informal as possible. 20 | 21 | #### During any workplace discussion: 22 | 23 | 1. we will not assume that you want to retire just because you are approaching a certain age, such as state pension age; and 24 | 2. we will not make discriminatory comments, suggesting that you should move on due to age. 25 | 26 | If you indicate that you are thinking of retiring, you are free to change your mind at any time until you have actually given notice to terminate your employment. 27 | 28 | Your employment or promotion prospects will not be prejudiced because you have expressed an interest in retiring or changing work patterns. 29 | 30 | If you express an interest in moving to a more flexible working pattern or changing role, we will confirm that this is what you want before any action is taken which could affect your employment, such as a change to your role or responsibilities. 31 | 32 | #### Giving notice of retirement 33 | 34 | If you have decided to retire, we would appreciate as much notice as possible, although you should give the company at least the notice you are obliged to give under your contract of employment. -------------------------------------------------------------------------------- /handbook/information-security/access-control.md: -------------------------------------------------------------------------------- 1 | # System Admins 2 | 3 | ### Responsibility 4 | 5 | - The System Admins for each of the systems DVELP uses are defined in the below 6 | table. It is the responsibility of the System Admin to make sure that only the relevant 7 | people have access to these systems and at the right permission level. 8 | 9 | ### Principle of Least Privilege 10 | 11 | - We operate on the principle of least privilege, which means individuals should have 12 | the minimum level of privilege in order to be able to perform their role 13 | effectively. 14 | 15 | ### Monthly review 16 | 17 | - System Admins conduct a thorough review of the permissions once every calendar 18 | month and adjust permissions ad hoc whenever required due to a person 19 | joining/leaving the team and/or a project starting/ending. 20 | 21 | ### Deputy System Admins 22 | 23 | - Deputy System Admins are required to have admin permissions on the relevant 24 | platforms. This is to enable them to handle urgent requests while System Admins 25 | are absent. Deputy System Admins are not required to conduct the thorough 26 | monthly review. 27 | 28 | | System | System Admin | Deputy System Admin | 29 | | ---------- | ------------------------------------------------------------------------ | ------------------- | 30 | | 1Password | Ruby Williams | Tom Mullen | 31 | | CircleCI | Tom Mullen | (single admin) | 32 | | Cloudflare | Vitalii Prodan | Ilya Lozer | 33 | | DocuSign | Ruby Williams | David Backhouse | 34 | | GCP | Vitalii Prodan | Tom Mullen | 35 | | GSuite | Ruby Williams | Tom Mullen | 36 | | Github | Ilya Lozer | Vitalii Prodan | 37 | | Glassdoor | Peter Sari | David Backhouse | 38 | | Greenhouse | Ruby Williams | Tom Mullen | 39 | | Heroku | Ilya Lozer | Vitalii Prodan | 40 | | Hubspot | David Backhouse | (single admin) | 41 | | Instagram | Peter Sari | David Backhouse | 42 | | LinkedIn | Peter Sari | David Backhouse | 43 | | Looker | Vitalii Prodan | Tom Mullen | 44 | | Mailchimp | Peter Sari | David Backhouse | 45 | | NPM | Dave Grix | Tom Mullen | 46 | | Papertrail | Ilya Lozer | Tom Mullen | 47 | | Sentry | Ilya Lozer | Tom Mullen | 48 | | Slack | Ruby Williams | Mark JL | 49 | | Stitch | Ilya Lozer | Tom Mullen | 50 | | Trello | Annise Makki | Mark JL | 51 | | Twilio | Varies on a project by project basis. Please contact the Project Manager | | 52 | | Twitter | Peter Sari | David Backhouse | 53 | | Youtube | Peter Sari | David Backhouse | 54 | 55 | ### Ownership 56 | 57 | Stephen Smith is the owner of this document. You can contact him on 58 | . 59 | -------------------------------------------------------------------------------- /handbook/information-security/anti-virus-malware-policy.md: -------------------------------------------------------------------------------- 1 | # Anti-Virus & Malware Policy 2 | 3 | This document covers the requirements to protect against malicious code, 4 | including but not exclusive to viruses, Trojans, ransomware, mail bombs, worms 5 | and mobile code - collectively known as malware. 6 | 7 | Malicious code can result in data loss, system damage and potentially severe 8 | disruption in service, which can lead to reputational damage and failure to 9 | deliver on our customer promise. 10 | 11 | The following guidelines aim to protect, to an appropriate level, the desktops, 12 | laptops and mobile devices of employees and contractors who deliver 13 | services to and on behalf of DVELP Ltd. 14 | 15 | * **Anti-virus software** must be installed, running and kept up-to-date on a 16 | weekly basis. If the software comes bundled as part of the Operating System 17 | (Windows 10 and above or MacOSX), auto-system updates must be enabled and 18 | installed within 1 day when prompted. 19 | 20 | * **Downloading and running software.** The following software should not be 21 | downloaded or run on any device used for any activity relating to DVELP. 22 | 23 | * Unlicensed software 24 | * P2P file sharing platforms (e.g. Limewire, Kazaa) 25 | * Software downloaded from the Dark Web 26 | * Software that allows remotely accessing your laptop without requiring 27 | explicit permission at the beginning of every session 28 | 29 | * **Spam, hoaxes and spear-fishing.** Many malware variants are sent via email, 30 | illegitmate websites or targeted attacks. Be aware of email from unknown 31 | senders, with topical subject lines and attachments. If you receive an email 32 | suspected to be malicious, be sure not to forward it on. 33 | 34 | * **Firewalls and sharing services.** All devices that support a firewall must 35 | have it enabled to prevent inbound and outbound traffic from unauthorised 36 | applications. All sharing services (screen, file, internet) must be disabled 37 | by default. In the event sharing is required by a trusted party, it may be 38 | enabled for and disabled immediately after the session. 39 | 40 | 41 | Although these guidelines cannot guarantee to fully protect against malware and 42 | associated adverse effects, their aim is to reduce the risk to both individual 43 | and DVELP as a whole. 44 | 45 | In the event a virus or other malware is identified, please report it to 46 | . 47 | 48 | ### Ownership 49 | 50 | Tom Mullen is the owner of this document. You can contact him on 51 | . 52 | -------------------------------------------------------------------------------- /handbook/information-security/asset-management.md: -------------------------------------------------------------------------------- 1 | # Asset Management 2 | 3 | ## Device Policy 4 | 5 | Devices covered by this policy include desktop computers, laptops, tablets and 6 | smartphones used to perform tasks on behalf of DVELP. They may be owned by the 7 | business or the individual. All devices must be encrypted and secured by a 8 | password or a biometric access control. All devices must be registered on the 9 | [Device 10 | Log](https://docs.google.com/spreadsheets/d/1DV6c4mM0YExWZbqztMBWbKUqNlQjDYSBWLHTuvpn3ls/edit#gid=90742438). 11 | 12 | ### BYOD Policy 13 | 14 | You may use your own device for work. This includes desktop computers, laptops, 15 | tablets and smartphones. 16 | 17 | ### Register of Devices 18 | 19 | All devices used for DVELP businesses must be registered on the [Device 20 | Log](https://docs.google.com/spreadsheets/d/1DV6c4mM0YExWZbqztMBWbKUqNlQjDYSBWLHTuvpn3ls/edit#gid=90742438). 21 | 22 | This forms a part of the onboarding process and must also be completed if 23 | further devices are acquired at a later date. 24 | 25 | On the Device Register, you are required to supply: 26 | 27 | * Device type (desktop computer, laptop, tablet or smartphone) 28 | * Manufacturer 29 | * Model 30 | * Serial number 31 | * Confirmation of encryption 32 | 33 | ### Loss of Devices 34 | 35 | If your device is lost or stolen, you must report it to 36 | without delay. You must change all passwords for your DVELP accounts. If it is 37 | possible to remotely wipe your device, you must do so. If you find evidence of 38 | unauthorised access to an account, report it to . 39 | 40 | ### Removal of Devices 41 | 42 | If you wish to retire a device, you must make sure you’ve logged out of all 43 | DVELP accounts and then completely wipe the device before disposing of it. You 44 | must notify that this has been done. 45 | 46 | When the production and security teams receive an email sent to 47 | it will be handled within 24h. 48 | 49 | ## Return of DVELP-Owned Assets 50 | 51 | All DVELP-owned computing resources must be returned upon separation from the 52 | company. Details will be defined in the [off-boarding 53 | checklist](../hr/off-boarding.md) in Charlie HR. 54 | 55 | ### Ownership 56 | 57 | Ruby Williams is the owner of this document. You can contact her on 58 | . 59 | -------------------------------------------------------------------------------- /handbook/information-security/backup-recovery-policy.md: -------------------------------------------------------------------------------- 1 | # Backup and Recovery Policy 2 | 3 | Technical and operational resiliency is a key objective of our Information 4 | Security Charter. 5 | 6 | This document provides guidelines to ensure the integrity and availability of 7 | data, which is critical to the running of client applications or day-to-day 8 | business at DVELP. 9 | 10 | 11 | ## Application Data 12 | 13 | Application data covers any data that is stored by any software application on 14 | DVELP servers, databases or document (blob) storage. It does not cover data 15 | that is held transiently in memory or background processes. 16 | 17 | 18 | ### Databases 19 | 20 | Any production environment managed by DVELP is to run on Heroku. Production 21 | databases, at a minimum, should be using the `Standard - 0` tier Heroku 22 | Postgresql database. 23 | 24 | Standard tier databases offer [Continuous Protection](https://devcenter.heroku.com/articles/heroku-postgres-data-safety-and-continuous-protection) to replicate the data through write-ahead logs, shipped to a datacentre for high-durability storage. In the event of a hardware failure, the logs can be used to reinstate the database to within seconds of the fault. 25 | 26 | Data can be rolled back up to 4 days. 27 | 28 | 29 | ### Document Storage 30 | 31 | Document, blob or cloud storage is often used to persist data relating to the 32 | application such as files or images. 33 | 34 | For all applications managed by DVELP, documents should be stored on Amazon S3. 35 | Each application should have its own bucket, following the naming conventions 36 | set out in this [guide](/guides/environments). 37 | 38 | For every new bucket created on S3, the following settings should be configured: 39 | 40 | * [Versioning](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html) 41 | * [MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html#MultiFactorAuthenticationDelete) 42 | 43 | 44 | ## Operational Data 45 | 46 | Operational data refers to any data, or documents that are created, 47 | processed or stored in the day-to-day running of DVELP. 48 | 49 | * *Legal documents*, including employment contracts, Master Services Agreements 50 | and Non-disclosure Agreements are to be created and stored on DocuSign. 51 | 52 | * *Standard documents*, including word processing documents, spreadsheets and 53 | other formats of document used to discuss, share and store information 54 | relevant to day-to-day operations of DVELP should be stored on Google Drive. 55 | 56 | It is recommended, but not essential that your Google Drive is synced with 57 | your local work station. 58 | 59 | * *Timesheets*, generated and saved historically on Harvest are backed up at 60 | least daily to Amazon Redshift on the DVELP Amazon Webservices (AWS) account. 61 | 62 | * *Sales opportunities*, generated and saved historically on Hubspot are backed 63 | up at least daily to Amazon Redshift on the DVELP Amazon Webservices (AWS) 64 | account. 65 | 66 | 67 | ## Project Data 68 | 69 | Project data covers all data and information that is relevant to the running of 70 | any given project. All projects run by DVELP are managed on Trello, each with a 71 | separate Trello board. 72 | 73 | Trello boards are not backed-up. Once Trello boards are 'closed' they can be 74 | reinstated. If a Trello board is closed and then deleted, it cannot be 75 | recovered. 76 | 77 | 78 | ## Communication Data 79 | 80 | Communication data covers all data transferred electronically via Slack or 81 | Gmail (for e-mail). 82 | 83 | Neither Slack nor Gmail are backed up manually. 84 | 85 | 86 | ## Mobile & Local Data 87 | 88 | Any business critical data that is stored locally on either a laptop or 89 | mobile device should be backed up to Google Drive or a similar cloud backup 90 | facility. 91 | 92 | Backups should be performed at least once a day. 93 | 94 | ### Ownership 95 | 96 | Tom Mullen is the owner of this document. You can contact him on 97 | . 98 | -------------------------------------------------------------------------------- /handbook/information-security/business-continuity.md: -------------------------------------------------------------------------------- 1 | # Business Continuity Plan 2 | 3 | DVELP with its remote first nature and cloud infrastructure, is not easily 4 | affected by typical causes of business disruption, such as local failures of 5 | equipment, power supplies, telecommunications, social unrest, terrorist attacks, 6 | fire, or natural disasters. Even so, threats considered in the context of 7 | business continuity are categorised by impact of the disruption. 8 | 9 | ## P1: Outage would have immediate impact on DVELP customer / user operations 10 | 11 | 1. Disruption of service of Herokuapp, specifically the AWS regions in which 12 | DVELP’s and DVELP’s clients are hosted. 13 | _ Effect: a loss of the Herokuapp service means that anyone who uses DVELP to 14 | host their applications would lose service. 15 | _ Solution(s): There are multiple AWS data centres globally to provide 16 | redundancy in the event of an outage 17 | 18 | 2. Unavailability of support staff in case of customer emergency. 19 | - Effect: emergency response times are greater than intended. 20 | - Solution(s): The team is distributed geographically (except during team 21 | get-togethers). The availability of developers will be determined by the SLA 22 | in place with the particular client. There is also an ongoing effort to 23 | document our overall on-call procedure, including escalation steps. 24 | 25 | ## P2: Outage would have immediate impact on DVELP ability to continue business 26 | 27 | 1. Malicious Software (Viruses, Worms, Trojan horses) attack. 28 | 29 | - Effect: depends on attack. 30 | - Solution(s): We outsource this protection to Heroku who have a range of 31 | measures in place to prevent this: https://www.heroku.com/policy/security 32 | 33 | 2. Hacking or other Internet attacks. 34 | - Effect: depends on attack. 35 | - Solution(s): We outsource this protection to Heroku who have a range of 36 | measures in place to prevent this: https://www.heroku.com/policy/security 37 | 38 | ## P3: Outage greater than 72 hours would have impact on DVELP ability to continue to do business 39 | 40 | Disruption of service from Github, Harvest, Forecast, Slack, Trello 41 | 42 | - Github 43 | - Restore master branch of codebase from local copies 44 | - Upload copies of codebase to relevant servers via SSH 45 | - Communication platforms 46 | - Failover to email for the majority of communications 47 | 48 | ## P4: Outage greater than 10 business days would have impact on DVELP ability to continue business 49 | 50 | Disruption of service from Google (gmail) 51 | 52 | - No failover plan currently. 53 | 54 | ### Ownership 55 | 56 | Stephen Smith is the owner of this document. You can contact him on 57 | . 58 | -------------------------------------------------------------------------------- /handbook/information-security/database-limits.md: -------------------------------------------------------------------------------- 1 | ## Database Limits Policy 2 | 3 | ### Row Limit 4 | 5 | For our development and staging databases sometimes we use Heroku's hobby-tier 6 | database plan. Heroku applies row limits depending on the tier used. 7 | 8 | When a database exceeds the hobby-tier row limit and we try to insert, we 9 | receive the Postgres error: 10 | 11 | `permission denied for relation ` 12 | 13 | The row limits of hobby-tier database plans are enforced with the following 14 | mechanism: 15 | 16 | 1. When a hobby-dev database reaches 7,000 rows, or a hobby-basic database hits 17 | 7 million rows, the owner receives a warning email stating they are nearing 18 | their row limits. 19 | 20 | 2. When the database exceeds its row capacity, the owner receives an additional 21 | notification. At this point, the database receives a 7-day grace period to 22 | either reduce the number of records, or migrate to another plan. 23 | 24 | 3. If the number of rows still exceeds the plan capacity after 7 days, `INSERT` 25 | privileges are revoked on the database. Data can still be read, updated, or 26 | deleted from the database. This ensures that users can bring their database into 27 | compliance and retain access to their data. 28 | 29 | 4. When the number of rows is again in compliance with the plan limit, INSERT 30 | privileges are automatically restored to the database. Note that database sizes 31 | are checked asynchronously, so it may take a few minutes for privileges to be 32 | restored. 33 | 34 | ### Storage Limit 35 | 36 | Storage capacity is a soft limit. Heroku-postgres recommend customers to stay 37 | under because this can make that database difficult to support. Storage usage 38 | can be monitored on heroku-postgres database page for exact application. 39 | 40 | At the same time heroku-postgres provides more than enough storage even on the 41 | standard-tier plan. So we often use only 2-3% of even the cheapest plan. 42 | 43 | ### RAM Limit 44 | 45 | The RAM limit is a hard limit. If we max out our memory, we will receive out of 46 | memory errors on our database and be unable to connect or perform queries. On 47 | such issues the alert will be sent to us from Sentry and Heroku. 48 | 49 | ### Actions 50 | 51 | The alerts of any connected issues from Sentry or Heroku will be sent to system 52 | admins (Exact persons can be seen 53 | [here](/handbook/information-security/access-control.md)). The relevant system admin is 54 | then responsible for taking the appropriate action to remedy the situation and 55 | avoid (continued) disruption to our service. 56 | 57 | On production environments this is will often require upgrading to a higher 58 | tier, while on development and staging environments a clean-up of the database 59 | to reduce its content is likely to be the appropriate course of action. 60 | 61 | ### Ownership 62 | 63 | Ilya Lozer is the owner of this document. You can contact him on 64 | . 65 | -------------------------------------------------------------------------------- /handbook/information-security/internal-security-audit.md: -------------------------------------------------------------------------------- 1 | # Internal Security Audit 2 | 3 | Biannually, the [Internal Auditor (IA)](../README.md#contacts) will audit 4 | company-wide adherence to the DVELP Information Security Policies. The dates for 5 | 2019-2020 are as follows: 6 | 7 | * Monday 18th March 2019 8 | * Wednesday 18th September 2019 9 | * Wednesday 18th March 2020 10 | * Friday 18th September 2020 11 | 12 | During the audit, the IA will confirm process policies are followed and that 13 | team members know where to find DVELP guidance for any potential scenario. 14 | During an audit, the IA will cover a random selection of requirements from each 15 | chapter of our [Information Security](../information-security/README.md) Policy 16 | and will challenge each team member on at least one requirement. 17 | 18 | These internal audits and any nonconformities identified will be recorded in the 19 | [Internal Audit 20 | Sheet](https://docs.google.com/spreadsheets/d/1wGXHbE6v7jsyy1Qbd7m7i04oCfzN-_57SXP0yhu_UUc/edit#gid=0). 21 | 22 | Internal audit records will be reported on at the management review meetings. 23 | 24 | Our performance in these internal audits will also be captured on our 25 | [Info-Sec Looker Dashboard](https://dvelp.eu.looker.com/dashboards/39). 26 | 27 | ### Ownership 28 | 29 | Ruby Williams is the owner of this document. You can contact her on 30 | . 31 | -------------------------------------------------------------------------------- /handbook/information-security/isms-meetings.md: -------------------------------------------------------------------------------- 1 | # Information Security Management Meetings 2 | 3 | The [Information Security Management Team](../README.md#contacts) regurlarly meets to review our 4 | Information Security Management System (ISMS) 5 | 6 | ## Cadence 7 | 8 | At the end of an Information Security Management Meeting the next meeting is 9 | scheduled. This will be at least once a quarter. 10 | 11 | ## Agenda 12 | 13 | The agenda of the Information Security Management Meetings comprises a review of 14 | our entire ISMS and is laid out in our [Agenda Template](https://docs.google.com/document/d/1cx8bazH4vZJEZtiGf06q9flLGIkU_p2lAemSE2goRQc/edit?usp=sharing) 15 | 16 | ## Minutes 17 | 18 | Attendance and Minutes of our Meetings are captured a GoogleDrive folder 19 | available 20 | [here](https://drive.google.com/drive/folders/1bssvzvm2X7t6jE32UI6fi-WoD2oF4a2K) 21 | 22 | ### Ownership 23 | 24 | Stephen Smith is the owner of this document. You can contact him on 25 | . 26 | -------------------------------------------------------------------------------- /handbook/information-security/people-security.md: -------------------------------------------------------------------------------- 1 | # People Security 2 | 3 | Our team is centric to everything we do, they are important to us. The following 4 | processes help ensure we continue to hire the right people and to keep them 5 | informed and up-to-date with relevant security trends and best practices. 6 | 7 | ## Screening New Hires 8 | 9 | All U.K. candidates must pass a Standard Disclosure and Barring Service (DBS) 10 | check, to cover any criminal records, along with an Electronic Identity check. 11 | 12 | For all international hires, the background check must cover, where legal, any 13 | recorded criminal history. 14 | 15 | The employment history of all candidates will be verified through references 16 | from at least 2 former employers, where available. 17 | 18 | ## Training 19 | 20 | All new hires will be introduced to our Charter and briefed on the information 21 | security 'fundamentals'. All employees are required to attend a security 22 | refresher session at least once a year, which covers Policy reviews and updates 23 | on best-practices. 24 | 25 | ## In-Play 26 | 27 | Relevant updates, trends and process improvements are shared regularly and 28 | discussed with the team via the #iso27001 Slack channel. 29 | 30 | ### Ownership 31 | 32 | Tom Mullen is the owner of this document. You can contact him on 33 | . 34 | -------------------------------------------------------------------------------- /handbook/information-security/physical-and-environmental-security.md: -------------------------------------------------------------------------------- 1 | # Physical and environmental security 2 | 3 | ## Secure areas 4 | 5 | ### Physical security perimeter 6 | 7 | There are two security perimeters that affect our operations: 8 | 9 | 1. Our London office 10 | 2. The locations of the Amazon Web Services data centres that run our remote servers 11 | 12 | ### Physical entry controls 13 | 14 | Our London office requires the use of swipe cards in order to access the 15 | building, our floor and our corridor. More information is available 16 | [here](https://members.wework.com/guide) 17 | 18 | ### Securing offices, rooms and facilities 19 | 20 | However, our office room itself does not have swipe card access. Instead each 21 | member of the team carries a key to the lock on the door. It is our policy to 22 | never leave the room unlocked if there is not at least one other team member in 23 | the room. 24 | 25 | In case of any office related emergencies, the WeWork emergency hotline can be 26 | found 27 | [here](https://members.wework.com/guide) 28 | 29 | ### Working in secure areas 30 | 31 | Secure areas for us are: 32 | 33 | - Our employees' homes 34 | - Our London office 35 | 36 | Whenever we are not in one of these secure areas we must: 37 | 38 | - respect the [off-premesis](#security-of-equipment-and-assets-off-premises) 39 | policy. 40 | 41 | ## Equipment 42 | 43 | ### Security of equipment and assets off-premises 44 | 45 | We often work in public places. This is because: 46 | 47 | - some members of our team work remotely from shared office spaces 48 | - we travel regularly to meet our clients and can work in transit 49 | 50 | In order to avoid any security breaches: 51 | 52 | - we never show and/or type passwords and access keys when others can see our 53 | screen 54 | - we never leave our devices unattended in public places 55 | 56 | ### Ownership 57 | 58 | Stephen Smith is the owner of this document. You can contact him on 59 | . 60 | -------------------------------------------------------------------------------- /handbook/information-security/risk-management.md: -------------------------------------------------------------------------------- 1 | ## Risk Management 2 | 3 | ### Risk Register 4 | 5 | The company [Risk 6 | Register](https://docs.google.com/spreadsheets/d/1gyK0zWSVlX-ZnXsN_c4-my86-hHjHEDY6IEP5h9UuVQ/edit?usp=sharing) 7 | tracks all of the risks that members of the DVELP team have identified. 8 | 9 | ### Identifying Risks 10 | 11 | All members of the DVELP team and all external stakeholders are asked to 12 | contribute to the identification of 13 | risks that we, as an organisation, face. Any newly identified risks can either 14 | be emailed in to [security@dvelp.co.uk](mailto:security@dvelp.co.uk) or, if 15 | you're a member of the DVELP team, directly added to our [Risk 16 | Register](https://docs.google.com/spreadsheets/d/1gyK0zWSVlX-ZnXsN_c4-my86-hHjHEDY6IEP5h9UuVQ/edit?usp=sharing). 17 | 18 | ### Risk Assessment 19 | 20 | Risks are assessed by their: 21 | 22 | - Likelihood, on a scale from 1-5 23 | - Severity if they were to occur, on a scale from 1-5 24 | 25 | The product of these two figures results in the measure of their Impact. 26 | 27 | ![Risk Assessment Matrix](../../assets/risk-impact.png) 28 | 29 | The impact of a risk is then categorised as: 30 | 31 | - **High**: Critical to the continued operation of DVELP, such as significant financial loss, major impact to reputation, loss of sensitive personal data 32 | - **Medium**: Requiring quick resolution, significant impact on DVELP's operations, such as significant impact on reputation, damaging the trust with a client and/or partner 33 | - **Low**: Can be accepted as normal business risk, mitigation plan not necessarily required 34 | 35 | ### Risk Mitigation 36 | 37 | Where the anticipated impact of an unmitigated risk Medium or High, the 38 | management team will work together to find a mitigating action that reduces the 39 | impact to below this threshold. 40 | 41 | ### Ownership 42 | 43 | Stephen Smith is the owner of this document. You can contact him on 44 | . 45 | -------------------------------------------------------------------------------- /handbook/information-security/special-interest-groups.md: -------------------------------------------------------------------------------- 1 | # Special Interest Groups 2 | 3 | In order to stay up to date with latest developments and threats, we are a 4 | member of a number of special interest groups. These are listed here. 5 | 6 | - [AWS User Group UK](https://www.meetup.com/AWSUGUK/) 7 | - [UK Cloud Security Meetup](https://www.meetup.com/Cloud-Security-Meetup/) 8 | - We Follow @AWSUserGroupUK on Twitter 9 | - We attend the City of London Police Cyber Griffin Events 10 | 11 | Stephen Smith is our representative in these special interest groups and updates 12 | the entire team on any recent threats and learnings every Monday during our 13 | Team Focus Meeting. 14 | 15 | ### Ownership 16 | 17 | Stephen Smith is the owner of this document. You can contact him on 18 | . 19 | -------------------------------------------------------------------------------- /handbook/information-security/supplier-policy.md: -------------------------------------------------------------------------------- 1 | # Supplier Policy 2 | 3 | In providing our services we rely on a number of third party suppliers that have 4 | access to some of the sensitive information we handle. This policy sets out how 5 | we vet our suppliers to ensure that they use appropriate measures to protect this sensitive data. 6 | 7 | ## Vetting Process 8 | 9 | We track all of our suppliers in our [Supplier 10 | List](https://docs.google.com/spreadsheets/d/14kog_nFut3v2t5mZNNatZ-oWb7tP3ImWdXjUP9EkZGc/edit?usp=sharing). 11 | 12 | When we start working with a new supplier, we add the supplier to this list and 13 | assess whether they will have access to [sensitive information](./classification-of-information.md). If so, they require vetting before this information can be shared. 14 | 15 | If vetting is required we: 16 | 17 | 1. Review the supplier's information security policy (if available) 18 | 2. Add them to our [Upguard Security Monitoring account](https://cyber-risk.upguard.com/vendorlist). 19 | 20 | Suppliers pass the supplier vetting process if one of the below is the case: 21 | 22 | 1. They are ISO27001 accredited 23 | 2. Their Upguard Cyber Risk Score is 700 points and above 24 | 3. We have a contract with the relevant employees of the supplier that requires them to comply with the DVELP information security policy 25 | 26 | ## Annual Review 27 | 28 | We review our supplier's information security policy on an annual basis to ensure they continue to provide the required level of data protection. 29 | 30 | ### Ownership 31 | 32 | Stephen Smith is the owner of this document. You can contact him on 33 | . 34 | -------------------------------------------------------------------------------- /handbook/information-security/vulnerability-management.md: -------------------------------------------------------------------------------- 1 | # Vulnerability Management 2 | 3 | ## Reporting of Incidents and Vulnerabilities 4 | 5 | We encourage our workforce and customers to report any security related 6 | incidents, vulnerabilities and questions to us at . Any 7 | report made to this email address is considered as an "Enquiry". 8 | 9 | ## Enquiry Tracking 10 | 11 | We use this [Trello Board](https://trello.com/b/Hx0o5GpZ/security-reporting) to 12 | track any incidents and vulnerabilities that have been reported to us. All 13 | emails sent to will be forwarded to this board and 14 | processed there. 15 | 16 | ## Enquiry Processing 17 | 18 | ### Enquiry Evaluation 19 | 20 | We evaluate enquiries within two working days of them being reported. 21 | 22 | At Enquiry Evaluation the [Information Security Officer](../README.md#contacts): 23 | 24 | 1. Assigns the right person on the DVELP team to investigate the issue. This 25 | person is added to the Trello Card and henceforth responsible for the 26 | management of the enquiry. We call this person the Enquiry Owner. 27 | 28 | 2. Performs an urgency assessment and assigns one of the below urgency levels: 29 | 30 | - High (to be managed by Enquiry Owner as soon as possible) 31 | - Medium (to be managed by Enquiry Owner within 5 working days) 32 | - Low (to be managed by Enquiry Owner within 3 weeks) 33 | 34 | ### Enquiry Management 35 | 36 | Once the Enquiry Owner takes on a task, 37 | 38 | - He or she conducts the required research to understand the implications of the 39 | enquiry 40 | - He or she will then implement a management plan that remedies any 41 | vulnerabilities 42 | - He or she considers any communications required to our stakeholders to inform them of 43 | the incident, it's implications and our management plan 44 | 45 | ### Enquiry Review 46 | 47 | Once the Management Plan has been implemented we will hold a review of the 48 | incident and our response to it. This review includes: 49 | 50 | - A retrospective on our performance in responding to the incident 51 | - An assessment of any improvements that we should introduce in our processes in 52 | order to capitalise on the learnings from the incident 53 | - A stress test to reassure the team that any vulnerabilities have been 54 | adequately remedied 55 | 56 | The Enquiry Review will involve at a minimum the Enquiry Owner and the 57 | [Information Security Officer](../README.md#contacts) but should be extended to 58 | include all members of the team with expertise relevant to the incident. 59 | 60 | ### Information Security Incidents 61 | 62 | At any point during the enquiry management process an enquiry can be identified 63 | as an Information Security Incident, in which case the management of the enquiry 64 | is escalated to the [Incident Response](incident-response.md) process. 65 | 66 | Please see the [Incident Response](incident-response.md) policy for details 67 | on how to identify an information security incident. 68 | 69 | ## Audit 70 | 71 | Please see our [Internal Security Audit](internal-security-audit.md) plan for 72 | details on the regular audit of this process. 73 | 74 | ## Continuous Monitoring 75 | 76 | We track our information security performance using our [Info-Sec Looker Dashboard](https://dvelp.eu.looker.com/dashboards/39) on which we track: 77 | 78 | - The outcome of our [Internal Security Audits](internal-security-audit.md) 79 | - The scores of our Info-Sec Quizzes 80 | - The velocity of our Info-Sec Trello Board Cards 81 | 82 | ### Ownership 83 | 84 | Stephen Smith is the owner of this document. You can contact him on 85 | . 86 | -------------------------------------------------------------------------------- /handbook/operations/docusign.md: -------------------------------------------------------------------------------- 1 | # DocuSign Process 2 | 3 | We use [DocuSign](https://www.docusign.co.uk/) to facilitate the process of signing official documents without requiring hard copies. 4 | 5 | We have one account and that is run by Ruby Williams. 6 | 7 | If you have a document that needs to be signed digitally, please email this to Ruby with instructions on who this needs to be sent to including names and email addresses. 8 | 9 | Once the document has been signed by all parties, Ruby will send you the signed PDF. It is then your job to file it in the appropriate place on the GoogleDrive. We do not use DocuSign as a file storage for all signed documents as only Ruby has access to it. 10 | 11 | Likely locations you will want to file signed documents include: 12 | * [Client folder](https://drive.google.com/drive/folders/1J2HEA6BF4USDY9HQ9rNmyn6_2ihmfmEw) for contractual agreements with clients 13 | * [CharlieHR](https://dvelp.charliehr.com/) for employment contracts of our team members (go to relevant individual -> documents -> contract) 14 | * [Recruiter Commmercial Terms](https://drive.google.com/drive/folders/1X6-eNAntXy4X3CnAEvREl87NPJsqUfP7) 15 | 16 | -------------------------------------------------------------------------------- /handbook/operations/greenhouse.md: -------------------------------------------------------------------------------- 1 | # Working with Greenhouse 2 | 3 | [Greenhouse.io](https://www.greenhouse.io/) is our Applicant Tracking System for 4 | candidates to join our team. 5 | 6 | ## Shared Approach 7 | 8 | Greenhouse is a great tool to coordinate the hiring process. However, in order 9 | for us to be able to rely on it, we need to follow these rules: 10 | 11 | **1. All candidates must go through Greenhouse** 12 | 13 | - If you come across a candidate that is not yet in Greenhouse: 14 | _ please create them on Greenhouse, uploading their CV if available 15 | _ if the candidate came through a recruiter please ask the recruiter to 16 | upload the candidate to our Greenhouse portal, so that they are tracked as 17 | the source of the candidate - If the recruiter does not yet have access to our 18 | Greenhouse portal, please ask the [Greenhouse System 19 | Admin](../README.md#contacts) to set this up 20 | 21 | **2. All communication about a candidate must go through Greenhouse** 22 | 23 | - If we discuss candidates via email or Slack, the information is not 24 | available to the whole team and likely to be forgotton 25 | - Therefore, when emailing: 26 | _ Send emails relating to a candidate from within Greenhouse (click the 27 | **Email Candidate** or **Email Team** button in the candidate's profile) 28 | _ Always CC the recruiter, so that they are up to speed with latest 29 | developments, as well as , which makes 30 | sure that any responses to your email are tracked in Greenhouse \* When a recruiter and/or candidate emails you directly, reply from within 31 | Greenhouse 32 | - For shorter messages you can use @mentions in the **Make a Note** section on 33 | the candidate profile. This will result in an email notification to the 34 | individual 35 | - If you have an offline conversation about a candidate, make sure the 36 | conclusions of this conversation are captured using the **Make a Note** 37 | field 38 | 39 | ## Activity Feed 40 | 41 | Every candidate has an Activity Feed. This is a timeline of all the 42 | communications, notes and actions that have been tracked relating to the 43 | candidate. If we have followed the above rules, we can rely on having 100% of 44 | the context regarding the candidate. If we have not followed the rules, it is 45 | likely there will be miscommunication and confusion that could have been 46 | avoided. 47 | 48 | ## Questions 49 | 50 | Any questions you have about the platform or our process can be directed at the 51 | [Greenhouse System Admin](../README.md#contacts). 52 | -------------------------------------------------------------------------------- /handbook/operations/hubspot.md: -------------------------------------------------------------------------------- 1 | # Tracking Deals with Hubspot 2 | 3 | We use [Hubspot](https://app.hubspot.com) to track potential deals that our 4 | sales team is working on. 5 | 6 | This document lays out our approach. 7 | 8 | ## Stages 9 | 10 | As a deal progresses through our sales process, it moves through the following 11 | stages, which we track on Hubspot: 12 | 13 | * Inbox 14 | * Sales Qualified Lead 15 | * Meeting Scheduled 16 | * Opportunity Confirmed 17 | * Proposal Submitted 18 | * Meeting to Discuss Proposal 19 | * Contract in Progress 20 | * Closed Won 21 | * Closed Lost 22 | 23 | ## Metrics We Track 24 | 25 | In order for us to analyse our performance as a sales team and to be able to 26 | plan around our sales pipeline, there are a number of metrics we track using 27 | Hubspot. These are captured as "Properties" of "Deals" and include: 28 | 29 | * **Forecast Amount**: This is the amount that we expect the deal to close for 30 | when it reaches the Sales Qualified Lead stage. It is set while the deal is at 31 | this stage and is not edited thereafter 32 | * **Forecasted Close Date**: This is the date that we expect the deal to close 33 | on when it reaches the Sales Qualified Lead stage. It is set while the deal is 34 | at this stage and is not edited thereafter 35 | * **Amount**: This is the amount of revenue we expect a deal to generate. It is 36 | continuously updated to reflect our best assessment of this value at any given 37 | time 38 | * **Close Date**: This is the date on which we expect the deal to close. It is 39 | continuously updated to reflect our best assessment of this date at any given 40 | time 41 | * **Probability**: This is the probability with which we expect the deal to 42 | close. This typically increases as deals move through the different stages. It 43 | is continuously updated to reflect our best assessment of this value at any 44 | given time 45 | * **Deal Owner**: This is the person that is responsible for closing the deal. 46 | They are responsible for the commercial management for all projects involving 47 | the specific client and they will be assigned the Sales Commission resulting 48 | from deals with that client. 49 | * **Project Start Date**: This is the date on which we expect the team to start 50 | working full time on the project. This is set as soon as an assessment can be 51 | made and no later than the Project Close Date 52 | * **Stage**: Our deals go through multiple stages in our sales pipeline. With each 53 | stage the probability that the deal closes and turns into a project increases. 54 | 55 | 56 | -------------------------------------------------------------------------------- /handbook/operations/interviewing.md: -------------------------------------------------------------------------------- 1 | # Interviewing 2 | 3 | We use Greenhouse to coordinate our interview process. Below you can find the steps you should take if you have been asked to interview one of our candidates. 4 | 5 | If you have any questions regarding this process, please get in touch with . 6 | 7 | ### 1. Visit Greenhouse and filter for the candidates you are currently responsible for 8 | 9 | Visit [Greenhouse](https://app2.greenhouse.io/people). Click `All Candidates`. 10 | 11 | ![Greenhouse Filter](../../assets/greenhouse_filter.gif) 12 | 13 | ### 2. Schedule Interview 14 | 15 | When you are assigned the coordinator of a candidate, it's your responsibility to schedule the next interview. Please email the candidate and their recruiter to arrange this from within Greenhouse by clicking on the `Email {Candidate First Name}` button. 16 | 17 | Make sure to copy in the `Agency Recruiter`. If we don't have the candidate's email address on record, only email the `Agency Recruiter`. 18 | 19 | ![Greenhouse Schedule Interview](../../assets/greenhouse_schedule_interview.gif) 20 | 21 | ### 3. Conduct Interview and Submit Scorecard 22 | 23 | After/during an interview fill in the relevant Scorecard on Greenhouse. See below for where to find this. 24 | 25 | ![Greenhouse Submit Scorecard](../../assets/greenhouse_submit_scorecard.gif) 26 | 27 | ### 4. Assign Ruby as coordinator 28 | 29 | Once you have conducted the interview you can hand the candidate back over to Ruby by assigning him as a coordinator. Ruby will then coordinate next steps for the candidate. 30 | 31 | ![Greenhouse Assign Coordinator](../../assets/greenhouse_assign_coordinator.gif) 32 | -------------------------------------------------------------------------------- /handbook/operations/invoicing.md: -------------------------------------------------------------------------------- 1 | # Invoicing Procedure 2 | 3 | ## Writing invoices 4 | 5 | This is the process that should be followed to invoice our clients for our work, one week at a time: 6 | 1. The project team works on a project for a week. 7 | 2. The following Monday morning (i.e. by noon) Project Managers review and sign-off on the hours reported by Developers for that week on Harvest. This [Utilisation Looker Dashboard](https://dvelp.eu.looker.com/dashboards/3) informs the Sign-off. 8 | 3. By the end of play on this same Monday, we send out invoices for the hours worked the previous week. 9 | 10 | 11 | ## Aged Receivables 12 | 13 | Every Monday, there will be an Invoicing Review at which we review our Aged Receivables: 14 | 15 | The [Invoicing Looker Dashboard](https://dvelp.eu.looker.com/dashboards/27?Untitled%20Filter=7%20days&filter_config=%7B%22Untitled%20Filter%22:%5B%7B%22type%22:%22past%22,%22values%22:%5B%7B%22constant%22:%227%22,%22unit%22:%22day%22%7D,%7B%7D%5D,%22id%22:6%7D%5D%7D) informs this Invoice Review. 16 | 17 | Overdue invoices are handled according to the below schedule. 18 | 19 | | Date | Action | Actioned by | 20 | | --------------------------------- | ---------------------------------------------- | ------------------------------- | 21 | | 1 Day after invoice was sent | Follow up to check invoice received/any issues | DVELP | 22 | | On the day that an invoice is due | Polite email reminder to say payment due | DVELP | 23 | | 7 days after invoice is due | Call to enquire about overdue invoice | DVELP | 24 | | 30 days after invoice is due | Reminder letter | External Debt Collection Agency | 25 | | 60 days after invoice is due | Final reminder before action letter | External Debt Collection Agency | 26 | | 67 days after invoice is due | Notice of intended proceedings | External Debt Collection Agency | 27 | | 74 days after invoice is due | Court action via online money claim | External Debt Collection Agency | 28 | 29 | 30 | -------------------------------------------------------------------------------- /handbook/professional-development/developer-proficiency.md: -------------------------------------------------------------------------------- 1 | # Developer Proficiency 2 | 3 | The following bands are designed to provide a structure to help better 4 | understand current competencies and act as a starting point for individualised 5 | discussions around progress. 6 | 7 | The criteria set out in each band is by no means exhaustive, but aims to provide 8 | a solid point of reference. 9 | 10 | ## Associate Developer 11 | 12 | * Pull Requests require multiple rounds of feedback to reach a mergeable state 13 | * The basics of a language or framework are mastered, but more advanced concepts 14 | are unfamiliar 15 | * Occasional issues following patterns and approaches within existing code bases 16 | * Most comfortable working on tightly scoped features or routine problems 17 | * Typically less than 2 years focused on a specific domain in a 18 | professional environment 19 | 20 | ## Developer 21 | 22 | * Pull Requests require occasional discussion around approach or implementation 23 | * Clearly able to identify and follow predefined patterns or approaches in an 24 | existing code base 25 | * Most comfortable working on clearly defined, well scoped features or 26 | problems 27 | * Typically 2-5 years focused on a specific domain in a professional 28 | environment 29 | * Being able to decide the priority level of a bug and set of the appropriate course of action 30 | * Being able to understand user stories and translate them into technical requirements 31 | * Being able to keep the client up to date on the day to day progress of a project 32 | 33 | ## Senior Developer 34 | 35 | * Pull Requests are a tool for communication of new features and a 36 | spring-board for higher-level discussions around approach 37 | * Experienced and comfortable through the entire lifecycle of a feature, from 38 | ideation to delivery 39 | * Can understand business drivers and make solid proposals to the relevant 40 | stakeholders for building new features or refining existing ones 41 | * A subject matter expert in at least one programming environment 42 | * Typically 5-8 years focused on a specific domain in a professional 43 | environment 44 | * As Scrum Master, taking responsibility for making sure our scrum process happens 45 | * Line managing other team members 46 | * Managing all client communication on a project 47 | * Being able to attend sales meetings and bring your technical expertise to the conversation 48 | * Using your technical knowledge to put together a plan based on client requirements (Solutions Engineering) 49 | 50 | ## Tech Lead 51 | 52 | * Pull Requests are a mentoring tool to engage less experienced teammates and 53 | showcase best practices 54 | * Highly adept at running and executing on multiple projects across multiple 55 | domains 56 | * Heavily involved in setting and maintaining professional standards for the 57 | organisation as a whole 58 | * A subject matter expert in a number of programming environments 59 | * Training other developers on both technical and non technical skills 60 | * Confident building and running small teams through substantial projects 61 | * Typically 8-12 years focused on a specific domain in a professional 62 | environment 63 | 64 | ## VP of Engineering 65 | 66 | * Focus on defining and progressing processes and innovation at a company-wide 67 | level 68 | * Fully capable of designing, owning and running entirely new, non-trivial 69 | systems 70 | * Confident building and running larger teams through long-running, complex 71 | projects with multiple-stakeholders 72 | * Recognised widely in the industry as having made substantial material 73 | contributions and considered a subject matter expert by peers 74 | * Typically 12-15+ years focused on a specific domain in a professional 75 | environment 76 | 77 | The bands are based on those set out by the team at 78 | [Basecamp](https://github.com/basecamp/handbook/blob/master/titles-for-programmers.md) 79 | 80 | -------------------------------------------------------------------------------- /handbook/professional-development/external-training-courses.md: -------------------------------------------------------------------------------- 1 | # External Training Courses 2 | 3 | We want everyone at DVELP to be able to progress their knowledge and understanding, 4 | with as little barrier to that as possible. 5 | 6 | The process for getting access to training materials should be as low as possible, 7 | and aid you in your day-to-day life at DVELP. 8 | 9 | ## Getting Access 10 | 11 | If you find an external training course/resource that you think would help you 12 | progress professionally, we encourage you to make a proposal to your Line Manager 13 | while setting your [personal goals](goal-reviews.md#personal-goals) each 3 months. 14 | 15 | Please ensure you consider your commitments to projects and daily work you 16 | already have. If you believe you need more time to complete the course, please 17 | discuss this with your Project Manager(s). 18 | 19 | Once agreed with your Line Manager that it's appropriate and will help you 20 | achieve your goals, please contact Tom Mullen with the details and cost of the 21 | course. Once approved, you may purchase access to the course and submit an expense 22 | using the [DVELP Expenses Platform](https://dvelp-expenses.firebaseapp.com/expenses). 23 | 24 | _Note:_ Agreement with your Line Manager is not enough - you have to discuss it 25 | with Tom Mullen before purchasing access to ensure your expense claim will be 26 | approved! 27 | 28 | ## Upon Completion 29 | 30 | Once you attend a course that has been funded by DVELP, please let Tom Mullen 31 | know you have completed it. We would also like you to share what you've learned 32 | with the team. This can be in any format you wish, for example you could: 33 | 34 | - Do a presentation (Think out Loud) 35 | - Create a blog post 36 | - Hold a workshop 37 | 38 | **This is not an optional element**, and you will be chased to do so upon course 39 | completion. We all want to learn and become better. 40 | 41 | ## Mandatory Training 42 | 43 | You may be asked to undertake mandatory training as part of your employment at 44 | DVELP - such as attending certification courses/examinations to gain accreditations. 45 | These follow the same process as courses you would like to attend. 46 | 47 | ### Ownership 48 | 49 | Tom Mullen is the owner of this document. You can contact him on 50 | . 51 | -------------------------------------------------------------------------------- /handbook/professional-development/mentoring.md: -------------------------------------------------------------------------------- 1 | # Mentoring 2 | 3 | At DVELP, we believe in `how` we do things. Although the end result is 4 | ultimately what we strive for, the steps we take to get there are extremely 5 | important. 6 | 7 | The belief in our process and a continued desire to improve it helps us to be 8 | more consistent as a team and more efficient in the day-to-day. It allows us to 9 | spend more time above the value line. 10 | 11 | As part of our commitment to this belief, we operate a mentor scheme to help new 12 | team members get up to speed. 13 | 14 | ## What is expected of a mentor? 15 | 16 | As a mentor to any new recruit, your overarching aim is to share the knowledge 17 | you have, but importantly listen to new experiences and see how we can 18 | improve collectively. 19 | 20 | The following will help guide you: 21 | 22 | - Spend time **pair programming** to work through your current project or task 23 | and share domain knowledge 24 | 25 | - **Discuss the fundamentals** such as Git (FF merges), linting and project 26 | setup. The Cookbook is a great place to start 27 | 28 | - Explain how to **efficiently manage time** to create a sustainable but 29 | productive working practice 30 | 31 | - Walk through the quirks of our **remote-first culture**, the fascination with 32 | `afk` and the importance of fluid conversation regular updates 33 | 34 | - Post a picture of some kittens to the `#random` channel 35 | 36 | - Explain why we **obsess around the details** and how the small things, like 37 | consistent naming conventions of environments help prevent catastrophe 38 | 39 | - Offer reassurance on **taking ownership for delivering code that works** and 40 | how to ship it to production with confidence 41 | 42 | - **Review pull requests** and offer constructive advice on how to improve code 43 | where possible 44 | 45 | - **Introduce existing team members** and share any key information about the 46 | day-to-day running of the project you're working on 47 | 48 | 49 | ## What can you expect as a mentee? 50 | 51 | As a newcomer to the team, you should at a minimum, expect the following from 52 | your assigned mentor and the wider team: 53 | 54 | - A **warm welcome**, followed by a one-on-one video call with all existing team 55 | members 56 | 57 | - An **on-boarding session** from your mentor to help you understand the 58 | ins-and-outs of how we do things, from development best practices (FF commits) 59 | to time tracking and booking holidays 60 | 61 | - Support and advice writing your first few features and **shipping to 62 | production** 63 | 64 | - A **point of contact** for any question, no matter how large or small 65 | 66 | - Help setting up all the relevant accounts (GitHub, Harvest, Charlie, Google 67 | apps etc.) 68 | 69 | - An **introduction to the project and team** that you will be working with 70 | 71 | ### Make Questions Multiple Choice 72 | 73 | Asking questions is a fundamental part to learning. We have a nifty trick to get to your answer more quickly: make the question multiple choice. 74 | 75 | By sending proposals along with your question, you will help the recipient to: 76 | 77 | - Get up-to-speed with the context 78 | - Show you have done research and are really stuck 79 | - Allow them to choose, augment or add to the proposed solutions 80 | 81 | A 'warm-up' question of 'hey, I'm working on this problem, have we solved it before?' is always good place to start. 82 | 83 | So remember, make sure the next time you ask a question, send some proposals too. 84 | 85 | ## How long should the mentorship last? 86 | 87 | The mentorship is aimed to help people become confident members of the team. 88 | The time required will change on a case-by-case basis, but we recommend that 89 | mentors give close support for at least the **first 4 weeks**. 90 | -------------------------------------------------------------------------------- /handbook/professional-development/smart-goals.md: -------------------------------------------------------------------------------- 1 | # Good practice on Setting Goals 2 | 3 | Our goal setting process is flexible and accommodates all kinds of goals. We 4 | want you to set goals that best fit with what you want to achieve. Your review 5 | goals are based on: 6 | 7 | * Internal and external feedback 8 | * Expectations of your role 9 | * Your own personal ambitions 10 | * The wider company goals 11 | 12 | The background to setting any goal is thinking about what we want to achieve. 13 | Both in our careers and personally. We encourage all our employees to think 14 | about their ambitions and discuss these regularly with their manager. 15 | 16 | Once we have a good idea of what we want to achieve, it's useful to break this 17 | into smaller steps, or goals. 18 | 19 | 20 | # SMART 21 | 22 | A good way to create goals is to follow the SMART format. This means when 23 | writing goals, we focus on each one having the following attributes: 24 | 25 | **Specific:** Try to keep each goal specific and clear. A narrower scope will 26 | help you focus more. 27 | 28 | **Measurable:** Trying to associate a number with your goal is the easiest way 29 | to achieve this. This is very useful in helping you say definitively that 30 | you've achieved your goal, avoiding subjectivity. It is also more motivating 31 | because you can track progress and see how close you are to achieving your 32 | goals. 33 | 34 | **Achievable:** A goal should be something you have the means to accomplish with 35 | the resources you have available. For example, if it's a personal goal - you 36 | shouldn't set a goal that will require a 10 person team and large budget to 37 | achieve. 38 | 39 | **Realistic:** Ambitious goals are motivating, we don't want to make our goals 40 | too easy to achieve or they become pointless. However, being over-ambitious can 41 | lead to pressure and frustration rather than motivation. As a company we want 42 | continuous improvement - you don't need to go from 1 to 100 in a week. 43 | 44 | **Time based:** Giving ourselves a time limit for goals helps to make sure 45 | they're not forgotten about. Our process has a convenient review point every 3 46 | months. It can also be useful to create some shorter term goals so everything 47 | isn't left until the end of the quarter. Equally, it's OK to have a longer term 48 | annual goal that you make gradual process on throughout the year. 49 | 50 | ### Summary The SMART methodology is widely adopted and seen as useful to help 51 | people set good goals. If you need help with using it, please speak to your line 52 | manager. This should be a useful process, but if it doesn't fit for your goal 53 | then don't worry. This document is a guide only, our review process can include 54 | any kind of goal as long as it's agreed with you and your manager. 55 | -------------------------------------------------------------------------------- /product-org/README.md: -------------------------------------------------------------------------------- 1 | # Product @ DVELP 2 | Our Playbook for creating products at DVELP. 3 | 4 | ## Our Mission 5 | To create solutions that help businesses revolutionise how they speak with 6 | their customers. 7 | 8 | ## Strategy 9 | To [identify White Space](#fill-the-white-space) in [Partner Solutions](partner-solutions), 10 | [Prototype rapidly](#get-close-with-customers) and validate hypothesis amongst 11 | our customer base. Pick winners early and [scale up](#scale-up) 12 | through strong vendor partner relationships. 13 | 14 | ### Get Close with Customers 15 | Through close relationships with customers we can recognise industry trends early 16 | and identify opportunities to add value through products 17 | 18 | ### Fill the White Space 19 | Our proximity to customers coupled with deep expertise in our 20 | [Partner Solutions](partner-solutions) means we are uniquely positioned to 21 | identify and fill `White Space` in existing solutions and deliver new features 22 | and prototypes to our customer base to rapidly validate hypotheses. 23 | 24 | ### Scale-Up 25 | Build a strong commercial and go-to-market framework with our 26 | [Partner Vendors](partner-solutions#propositions) through which we can scale-up products 27 | that have shown early success with existing customers. 28 | 29 | ## Product Team 30 | * Chief Product Officer: Tom Mullen 31 | * Senior Vice President of Product: Damian Kellly 32 | * Vice President of Product Engineering: TBC 33 | 34 | A definition of key product roles can be found [here](roles). 35 | 36 | ## What We Believe In 37 | We believe, above all else, in the following principles, which act as guides to 38 | help us build incredible products: 39 | 40 | #### Focus Above the Value Line 41 | We spend as much time and focus as we can on things that will add value to our 42 | customers and to the end user. 43 | 44 | #### Ship Early and Often 45 | We don't like big bang releases. We break down complex tasks and ship small 46 | features regularly to get early feedback and reduce risk. 47 | 48 | #### We Are About Quality 49 | At our core, we are about quality. We obsess over detail. 50 | 51 | ## Resources 52 | * [Product Estate](https://docs.google.com/spreadsheets/d/16UzzS_aGoPzv1ThoknyqM4NJ3k09QN5M3B7DtxIKY2o) 53 | * [Product Strategy Sheet](https://docs.google.com/spreadsheets/d/1YR6lM9HXHw2rkY1h2xiqOByDMlc0-1attTKJflA7A9w) 54 | 55 | ## Scope of Ownership 56 | The product team is responsible for both home-grown `Product` and `Partner 57 | Solutions`. More information about each can be found below. 58 | 59 | * [Product](product) 60 | * [Partner Solutions](partner-solutions) 61 | 62 | ## Key Event Calendar 63 | The product organisation rotates around key events throughout the financial year 64 | To bring structure and help ensure regular cadence. 65 | 66 | You can see the event calendar, along with outlines of each event 67 | [here](key-event-calendar.md). 68 | 69 | ## Contributing 70 | **We value your input.** Find out how to contribute to the Product 71 | Organisation, either through features, bugs or net new products and 72 | propositions [here](contributing). 73 | 74 | -------------------------------------------------------------------------------- /product-org/contributing/README.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | We take a `bottom up approach` to product development, which means we want to 3 | hear your opinion. Whether a customer a teammate or an end user, we want to hear 4 | from you. 5 | 6 | ## Existing Products 7 | If you have some feedback, a feature request or potentially a bug that you would 8 | like us to look at, please complete this [form](). 9 | 10 | Requests for existing products will be reviewed as follows: 11 | 12 | * **Bugs:** Same day 13 | * **Feature Requests & Feedback:** Monthly 14 | 15 | Requests will be triaged, discussed and if we feel are suitable planned into the 16 | product roadmap in the case of bugs, escalated for resolution. 17 | 18 | ## Net New Products 19 | We believe the greatest ideas originate from those who are closest to the 20 | problem and closest to the customer. If you have an idea for a new product or 21 | have identified an industry trend or repeated customer problem, we want to help 22 | you realise the solution. 23 | 24 | To share your insights and ideas with us, please take the time to complete a 25 | [canvas](https://sabioltd.sharepoint.com/:p:/s/Execution-CloudFocus/ESaOBYOz-W5PnT0krqU6U_kBEGDEk_4qdBmjvt-7mY1KKw?e=BnEetd). 26 | 27 | We will review canvases every 6 weeks where we will invite you to an open forum 28 | to elaborate on the canvas and discuss feasibility for delivery. 29 | 30 | Details of all stages for Net New Product delivery are as follows: 31 | 32 | * **Ideation:** Draw up an initial canvas and submit it to the product team 33 | * **Discussion Forum:** Open forum to discuss new canvas ideas (6 weekly) 34 | * **Extended business plan:** An extended (5-6 page) business plan, including 35 | financials, for the product 36 | * **Budgeting:** Budget approval for the investment 37 | * **Resourcing:** Assemble the team to `Own The Product` 38 | * **Build:** Build! 39 | -------------------------------------------------------------------------------- /product-org/interfaces/README.md: -------------------------------------------------------------------------------- 1 | # Product Team: Interfaces 2 | * [Finance](#finance) 3 | * [Marketing](#marketing) 4 | * [Sales & Account Management](#sales-account-management) 5 | * [Professional Services](professional-services) 6 | * [Support](#support) 7 | 8 | ## Finance 9 | The Product team interfaces with Finance and is responsible for providing them 10 | with: 11 | 12 | * Resource requirements 13 | * Annual Forecasts 14 | * Consumption reports for reconciliation 15 | 16 | ## Marketing 17 | The Product team interfaces with the Marketing team through dedicated Product 18 | Marketing Managers (PMM). 19 | 20 | The Product team is responsible for providing the PMM with: 21 | 22 | * [Product Canvas](https://sabioltd.sharepoint.com/:p:/s/Execution-CloudFocus/ESaOBYOz-W5PnT0krqU6U_kBEGDEk_4qdBmjvt-7mY1KKw?e=BnEetd) 23 | * Roadmap 24 | * Feature Releases 25 | 26 | The responsibilities of the PMM can be found 27 | [here](../roles/product-marketing-manager). 28 | 29 | ## Professional Services 30 | The Product Team is responsible for providing the Professional Services and 31 | delivery teams with the relevant material and support help facilitate client 32 | implementation. As follows: 33 | 34 | * Changelogs 35 | * Feature updates 36 | * Technical Documentation 37 | * Training courses 38 | * Proposed commercial packages 39 | * Pricing calculators 40 | * Cheatsheets 41 | 42 | ## Sales & Account Management 43 | The Product team interfaces with the Sales & Account Management organisation and 44 | is responsible for providing them with: 45 | 46 | * Battlecards 47 | * Pricing tools and strategies 48 | 49 | ## Support 50 | The Product team interfaces with Support and is responsible for providing them 51 | with: 52 | 53 | * 1st & 2nd tier support guidelines 54 | * New feature release documentation and training 55 | * 3rd Tier escalation 56 | 57 | -------------------------------------------------------------------------------- /product-org/key-event-calendar.md: -------------------------------------------------------------------------------- 1 | # Key Event Calendar 2 | The following diagram covers the key events we conduct throughout the year to 3 | provide structure and maintain momentum. 4 | 5 | ![alt text](https://raw.githubusercontent.com/DVELP/cookbook/master/assets/product-cadence.png "Product Cadence") 6 | 7 | ## Product Forums 8 | We conduct Product Forums every 6 weeks. 9 | 10 | The Forum is designed to continually evaluate new and existing products or 11 | propositions and to provide structure and visibility to create a 12 | cyclical process. 13 | 14 | The Forum is open for a day, during which time we invite our teams and other 15 | stakeholders across the business to share, discuss and evaluate their ideas with 16 | us. 17 | 18 | The product forums will be broken down into the following segments to help guide 19 | progress through the cycle: 20 | 21 | ![alt text](https://raw.githubusercontent.com/DVELP/cookbook/master/assets/product-offer-evaluation.png "Product Evaluation") 22 | 23 | - [Evaluate Opportunity](#evaluate-opportunity) 24 | - [Concept Proposition](#concept-proposition) 25 | - [Investment](#investment) 26 | - [Launch Check](#launch-check) 27 | - [Evaluate Success](#evaluate-success) 28 | 29 | ### Evaluate Opportunity 30 | We welcome all ideas and any feedback or insight that can be shared to help us 31 | get a better understanding of our customer needs, product gaps or market 32 | opportunities. 33 | 34 | If you have a feature or [Net New Product](contributing/#net-new-products) 35 | idea you would like to discuss, all we ask is that you send over your 36 | [canvas]() 1 week in advance so we have time to prepare. 37 | 38 | We will typically spend 30 minutes per canvas. 39 | 40 | At the end of each discussion you should have a clear plan for next steps to 41 | move it forward. 42 | 43 | ### Concept Proposition 44 | - What is the proposed offer and how is it differentiated in the market? 45 | - Should/can we build this? 46 | - Is the market opportunity large enough to justify focus and investment? 47 | - What's the resource requirement and who is needed to deliver it? 48 | 49 | ### Investment 50 | - What's the offer? 51 | - Is it aligned with our strategic initiatives? 52 | - How many people are needed to build and support it? 53 | - What's the ROI timeframe? 54 | - What are the risks? 55 | 56 | ### Launch Check 57 | - Is the product ready for public consumption (MVP)? 58 | - Is the offer ready to launch commercially? 59 | - What are the risks and dependencies? 60 | - What are the key metrics to measure success? 61 | 62 | ### Evaluate Success 63 | - How is the offer delivering against KPIs? 64 | - What is the market feedback? 65 | - What opportunities are there for improvement or iteration? 66 | 67 | ## Annual Business Review & Budgeting 68 | In the last 6 weeks of the financial year, we will conduct a series of sessions 69 | in preparation for the coming financial year. These will include: 70 | 71 | - Extended QBR 72 | - Product Forum 73 | - Discuss and define key strategic themes 74 | - Resource planning and funding review for existing and new products 75 | 76 | ## Quarterly Business Review (QBR) 77 | QBR are run at the beginning of each Financial Quarter and are retrospective. 78 | The QBR will encapsulate, but is not limited to the following: 79 | 80 | - Financial performance review 81 | - Roadmap review and progress check 82 | - Individual product budget and resource requirement review 83 | - Celebrate key wins 84 | - Guest speakers 85 | 86 | As part of the QBR, we will also run a [Product Forum](#product-forums) for new 87 | ideas. 88 | -------------------------------------------------------------------------------- /product-org/partner-solutions/README.md: -------------------------------------------------------------------------------- 1 | # Partner Solutions 2 | Partner Solutions are defined by any technology or platform that we resell, 3 | promote, implement or support for our customers. 4 | 5 | The scope of ownership extends to associated consultancy services to help 6 | our customers identify opportunities to excel at customer experience 7 | and support procedural and technical innovation to deliver it. 8 | 9 | ## Propositions 10 | The following is an overview of the Partner Solutions we major in. 11 | 12 | **Digital** 13 | * [CX Company](#cx-company) 14 | * [Google](#google) 15 | * [Nuance](#nuance) 16 | 17 | **Insights** 18 | * [Verint](#verint) 19 | 20 | **Solutions** 21 | * [Avaya](#avaya) 22 | * [Colt](#colt) 23 | * [Gamma](#gamma) 24 | * [Genesys](#genesys) 25 | * [Semaphone](#semaphone) 26 | * [Twilio](#twilio) 27 | 28 | ## Digital 29 | 30 | ### CX Company 31 | **Partner Liasion:** TBC 32 | 33 | ### Nuance 34 | **Partner Liasion:** TBC 35 | 36 | ### Google 37 | **Partner Liasion:** Stu Dorman 38 | 39 | ## Insights 40 | 41 | ### Verint 42 | **Partner Liasion:** TBC 43 | 44 | ## Solutions 45 | 46 | ### Avaya 47 | **Partner Liasion:** TBC 48 | **Status:** TBC 49 | 50 | ### Colt 51 | **Partner Liasion:** TBC 52 | 53 | ### Gamma 54 | **Partner Liasion:** TBC 55 | 56 | ### Genesys 57 | **Partner Liasion:** TBC 58 | **Status:** Gold 59 | 60 | ### Semaphone 61 | **Partner Liasion:** TBC 62 | 63 | ### Twilio 64 | **Partner Liasion:** Stu Dorman 65 | **Status:** Gold 66 | 67 | ## Canvases 68 | The associated canvas for each product can be found [here](https://sabioltd.sharepoint.com/:p:/s/Execution-CloudFocus/ESaOBYOz-W5PnT0krqU6U_kBEGDEk_4qdBmjvt-7mY1KKw?e=BnEetd). 69 | -------------------------------------------------------------------------------- /product-org/product/README.md: -------------------------------------------------------------------------------- 1 | # Product 2 | Product is defined as technology that is owned by the business. It encapsulates 3 | anything built by the Product engineering team or acquired and integrated into 4 | the Product team. 5 | 6 | Product may be dependent on 3rd party vendors for component parts (through OEM) 7 | but the Intellectual Property (IP) to the complete solution must be owned by the 8 | business. 9 | 10 | ## Estate 11 | * [Airline](../products#airline) 12 | * [Autopilot](../products#autopilot) 13 | * [Flex Answer](../products#flex-answer) 14 | * [MaaS](../products#maas) 15 | * [Navigator](../products#navigator) 16 | * [Peformance Testing](../products#performance-testing) 17 | * [RaaS](../products#raas) 18 | * [Rapport](../products#rapport) 19 | * [SoftPhone](../products#softphone) 20 | * [SuperChannel](../products#supperchannel) 21 | * [VQMaaS](../products#vqmraas) 22 | 23 | ## Responsibility 24 | The Product Team is responsible for: 25 | 26 | * Ideation and validation 27 | * Commerical proposition 28 | * Budgeting and full P&L ownership 29 | * Product Roadmaps 30 | * Product engineering & delivery 31 | * Go To Market Strategy 32 | * Product Support 33 | 34 | ### Org Structure 35 | ![alt text](https://raw.githubusercontent.com/DVELP/cookbook/master/assets/product-org-structure.png "DVELP Product Org") 36 | 37 | ## Interfaces 38 | The Product Team interfaces with a number of other departments in the business, 39 | including Finance, Marketing, Sales & Account Management, Professional Services 40 | and Support. 41 | 42 | Details of the different interfaces can be found [here](../interfaces). 43 | 44 | ## Delivering the Strategy 45 | The business objective is to deliver 25% of all revenue through `Product` and 46 | `Partner Solutions` by September 2023. 47 | 48 | ## Annual Themes 49 | To keep us focused, each year we establish key themes on which we aim to 50 | either further our existing offerings or identify and establish net new products 51 | or solution sets. 52 | 53 | ## Product Lifecycle 54 | To help consistency and retain transparency, We identify and build features and 55 | products to a pre-defined product lifcycle. 56 | 57 | The details of a typical product lifecycle can be found 58 | [here](../lifecycle). 59 | -------------------------------------------------------------------------------- /product-org/product/lifecycle.md: -------------------------------------------------------------------------------- 1 | ## Product Life-cycle 2 | A typical product will follow the 4 stages of life-cycle outlined below. 3 | 4 | ## 1) Ideation 5 | Ideation covers both Net New products and new features or functionality within 6 | existing products. 7 | 8 | ### Net New Products 9 | Net New products, budgets and resources are identified and assigned annually. 10 | We take a bottom-up approach to Net New product ideation. The details can be 11 | found below. 12 | 13 | ### Features and Functionality 14 | New features and functionality can be proposed at any time, from anyone 15 | (internal or external). 16 | 17 | The new feature pipeline is reviewed every 6 weeks and the inbox is reviewed by 18 | the product team and any accepted features are prioritised for future delivery. 19 | 20 | The details on how to contribute to products can be found 21 | [here](../#contributing). 22 | 23 | ## 2) Build 24 | Our approach to building products is closely aligned with the Agile 25 | methodologies. 26 | 27 | ### Roadmap 28 | To help translate the strategic vision of the product into deliverables and to 29 | facilitate communication with internal and external stakeholders, we maintain a 30 | roadmap. 31 | 32 | Roadmap planning happens once per quarter. During Roadmap planning, all new 33 | feature requests and other proposals will be considered and planned in 34 | appropriately. 35 | 36 | ### Ceremonies 37 | We follow `SCRUM` and typically work in 2-week sprints. The sprints are 38 | supported by key ceremonies including `planning`, `backlog grooming` and 39 | `retrospectives`. 40 | 41 | Typically our delivery teams will focus 4 sprints on Roadmap items and features 42 | followed by 1 sprint of bug fixing and reducing technical debt. 43 | 44 | ## 3) Release 45 | Once the product or feature is ready to be shared with the world, it will run 46 | through the following stages: 47 | 48 | * Early Access Release 49 | * Alpha 50 | * Beta 51 | * General Availability 52 | 53 | The details of each of these phases can be found [here](../release-phases) 54 | 55 | ## 4) Feedback 56 | Collecting feedback from our customers, our team mates and end users is 57 | essential to on-going product improvements. 58 | 59 | Please do share your [contribution](../product). 60 | 61 | -------------------------------------------------------------------------------- /product-org/product/products.md: -------------------------------------------------------------------------------- 1 | # Products 2 | The following are the products that make up the `Product Estate`. 3 | 4 | ### Airline 5 | **State:** Active Development 6 | **Product Owner:** Damian Kelly 7 | **Lead Product Engineer:** Ilya Lozer 8 | 9 | INSERT ELEVATOR PITCH 10 | 11 | ### Autopilot 12 | **State:** Active Development 13 | **Product Owner:** Jose Luis Zamorano 14 | 15 | INSERT ELEVATOR PITCH 16 | 17 | ### Flex Answer 18 | **State:** Active Development 19 | **Product Owner:** Yemi 20 | 21 | INSERT ELEVATOR PITCH 22 | 23 | ### MaaS 24 | **State:** Support 25 | **Product Owner:** TBC 26 | 27 | INSERT ELEVATOR PITCH 28 | 29 | ### Navigator 30 | **State:** Support 31 | **Product Owner:** Richard Beard 32 | 33 | INSERT ELEVATOR PITCH 34 | 35 | ### Performance Testing 36 | **State:** Support 37 | **Product Owner:** Jose-Luis Zamorano 38 | 39 | INSERT ELEVATOR PITCH 40 | 41 | ### RaaS 42 | **State:** Support 43 | **Product Owner:** TBD 44 | 45 | INSERT ELEVATOR PITCH 46 | 47 | ### Rapport 48 | **State:** Support 49 | **Product Owner:** Richard Beard 50 | 51 | INSERT ELEVATOR PITCH 52 | 53 | ### SoftPhone 54 | **State:** Support 55 | **Product Owner:** Jose-Luis Zamorano 56 | 57 | INSERT ELEVATOR PITCH 58 | 59 | ### SuperChannel 60 | **State:** Active Development 61 | **Product Owner:** Jose-Luis Zamorano 62 | 63 | INSERT ELEVATOR PITCH 64 | 65 | ### VQMaaS 66 | **State:** Support 67 | **Product Owner:** TBD 68 | 69 | INSERT ELEVATOR PITCH 70 | 71 | ## Product States 72 | | State | Description | 73 | |--------------------|-----------------------------------------------------------| 74 | | Active Development | Clearly defined roadmap, regular delivery cadence | 75 | | Support | No roadmap for new features | 76 | 77 | ## Canvases 78 | The associated canvas for each product can be found [here](https://sabioltd.sharepoint.com/:p:/s/Execution-CloudFocus/ESaOBYOz-W5PnT0krqU6U_kBEGDEk_4qdBmjvt-7mY1KKw?e=BnEetd). 79 | 80 | -------------------------------------------------------------------------------- /product-org/product/release-phases.md: -------------------------------------------------------------------------------- 1 | # Release Phases 2 | The following are the typical release phases for our products and features. 3 | 4 | #### Early Access Programme 5 | First outing of any product or feature to a small subset of customers who have 6 | are registered on the Early Access Programme. 7 | 8 | Not recommended for anything other than sandbox and demos. 9 | 10 | #### Alpha 11 | Extended pool of testing, can be used for small number of end user interactions. 12 | Not a stable release, expect bugs. 13 | 14 | #### Beta 15 | Public release, but limited support. Not recommended for production deliveries. 16 | 17 | #### General Availability 18 | Fully available, stable release and covered by support. Production ready!! 19 | -------------------------------------------------------------------------------- /product-org/roles/README.md: -------------------------------------------------------------------------------- 1 | # Roles 2 | The following are definitions and responsibilities of key roles within the 3 | product organisation. 4 | 5 | * [Lead Product Engineer](lead-product-engineer.md) 6 | * [Product Designer](product-designer.md) 7 | * [Product Engineer](product-engineer.md) 8 | * [Product Marketing Manager](product-marketing-manager.md) 9 | * [Product Owner](product-owner.md) 10 | -------------------------------------------------------------------------------- /product-org/roles/lead-product-engineer.md: -------------------------------------------------------------------------------- 1 | # Lead Product Engineer 2 | The Lead Product Engineer drives the technical direction of the product and is 3 | responsible for defining and ensuring best-practice. Our Lead Product Engineers 4 | are laser focused on creating the best engineering solutions possible. 5 | 6 | ## Responsibilities 7 | Our Lead Product Engineers are the technical figure heads in a given Product 8 | 'pod'. The Lead Engineer oversees and is responsible for all technical output 9 | from their Product Engineering Team. 10 | 11 | * Define and deliver engineering best practice, including technology choices 12 | * Own the personal and technical proficiency roadmap for Product Engineers 13 | * Ensure delivery of feature and roadmap requirements 14 | * Responsible for reliability and support 15 | 16 | ### Engineering First 17 | Our Lead Product Engineers are always Engineering first. There is a duty of care 18 | to the [Product Owner](../product-owner) to deliver against roadmap items and 19 | critical features, but this always done with engineering best-practice in mind. 20 | 21 | ### Set The Standard 22 | Lead Product Engineers are not only responsible for continually redefining 23 | best-practice, but they are equally responsible for setting the bar for their 24 | engineering teams. Our Lead Engineers have extensive experience at the coalface 25 | and can lead highly successful teams through strategic thinking. 26 | 27 | ### Focus Above the Value Line 28 | Our Lead Product Engineers focus above the value line. They challenge themselves 29 | to make decisions and spend time creating tangible value for customers. 30 | 31 | ## Communication 32 | The Lead Product Engineer has two key stakeholder sets for communication: 33 | 34 | ### Internal 35 | * *Engineering:* Set standards for, motivate and mentor [Product 36 | Engineers](../product-engineer) 37 | * *Product Owner:* Collaborate with the [Product Owner](../product-owner) to 38 | deliver the roadmap 39 | * *VP of Product Engineering:* Work closely with the VP of Product Engineering 40 | to improve platform and developer toolsets 41 | 42 | ### External 43 | * *Customers:* Build a process to continuously collect and evaluate customer 44 | feedback 45 | 46 | ## Reporting 47 | Our Lead Product Engineers work alongside the [Product Owner](../product-owner) 48 | and report directly in to the VP of Product Engineering. 49 | -------------------------------------------------------------------------------- /product-org/roles/product-designer.md: -------------------------------------------------------------------------------- 1 | # Product Designer 2 | Our Product Designers are fundamental to the product creation process. Designers 3 | help turn concepts into solutions. 4 | 5 | As a Product organisation we are focused on aesthetics and ergonomics 6 | in equal measure. Our Product Designers have deep expertise in balancing both 7 | requirements to create solutions that deliver seamless user experience with 8 | on-point look and feel. 9 | 10 | ## Responsibilities 11 | Our Product Designers take full responsibility for all aspects of product 12 | design, including but not exclusive to: 13 | 14 | - UI Design (full lifecycle) 15 | - UX Design (full lifecycle) 16 | - Product Marketing Material 17 | 18 | ### Translate 19 | A key requirement of our Product Designers is to work closely with engineering 20 | teams to translate complex technical problems into real-world, customer facing 21 | solutions that focus on delivery of value and ease of use. 22 | 23 | Our Product Designers act as the mouthpiece of the customer to create an open 24 | and continual feedback loop. 25 | 26 | ### Own The Journey 27 | Our Product Designers are expected to own the customer journey through any given 28 | product. The Journey starts at discovery material and works through initial 29 | on-boarding and engagement to continued consumption. 30 | 31 | ### Pixel Perfect 32 | We obsess over detail and value aesthetics in the highest regard. Our Product 33 | Designers are Pixel Perfect. 34 | 35 | ### Continual Innovation 36 | Our products are living, breathing entities, which require continued attention 37 | and iterative improvement. Our Product Designers operate a data-lead approach to 38 | continual innovation. 39 | 40 | ## Communication 41 | The Product Designer has two key stakeholder sets for communication: 42 | 43 | ### Internal 44 | * *Engineering:* Work closely with engineering teams to design user journey's 45 | and provide clear and consistent feedback from customers 46 | * *Sales & Marketing:* Provide relevant product design packs to support Sales 47 | and Marketing initiatives 48 | * *Product Management:* [Report](#reporting) key updates on UI & UX design, 49 | which are on the critical delivery path 50 | 51 | ### External 52 | * *Customers:* Build a process to continuously collect and evaluate customer 53 | feedback 54 | 55 | ## Reporting 56 | Our Product Designers may work on a single product or across an array of smaller 57 | products. In each case, they report directly in to the 58 | [Product Owner](../product-owner). 59 | -------------------------------------------------------------------------------- /product-org/roles/product-engineer.md: -------------------------------------------------------------------------------- 1 | # Product Engineer 2 | The Product Engineer, whether front-end, back-end or full-stack is at the heart 3 | of the value chain. Our Product Engineers aim to write as little code as 4 | possible to deliver streamlined and precision products to customers. 5 | 6 | ## Responsibilities 7 | * Full Feature life-cycle management 8 | * Ensuring code quality and longevity of functional implementations 9 | * Translating user-stories into working digital solutions 10 | * Enabling design and UAT 11 | * Bug fixing & tech-debt management 12 | * On-call support 13 | 14 | ### Technical Excellence 15 | Our Product Engineers deliver technical excellence at every step of the process. 16 | They fundamentally understand the importance of tried and tested programming 17 | practices to create solutions that are built to last. Each line of code is 18 | meticulously reviwed and deliberated upon to ensure continued adherence. 19 | 20 | Our engineering team continues to redefine best-practice. 21 | 22 | ## Communication 23 | The Product Engineer has two key stakeholder sets for communication: 24 | 25 | ### Internal 26 | * *Lead Product Enginer:* [Report](#reporting) progress on features, associated 27 | epics and discussion on target architecture and implementation choices 28 | * *Product Management:* key updates on features which are on the critical 29 | delivery path 30 | * *Product Designer:* Close working relationship to prototype ideas and provide 31 | staged solutions for sign-off pre-production 32 | 33 | ### External 34 | * *Customers:* All member of the product team, including Engineers owe a duty of 35 | care to customers, to listen to issues and identify areas for improvement 36 | 37 | ## Reporting 38 | Our Product Engineers will typically be dedicated to a single product and will 39 | report to both the [Lead Product Engineer](../lead-product-engineer) for technical 40 | decisions and guidance and to the [Product Owner](../product-owner) for task 41 | prioritisation and strategic direction. 42 | -------------------------------------------------------------------------------- /product-org/roles/product-marketing-manager.md: -------------------------------------------------------------------------------- 1 | # Product Marketing Manager 2 | The Product Marketing Manager spearheads the Go-To-Market (GTM) activity for the 3 | individual product or offering. 4 | 5 | Our Product Marketing Managers are responsible for creating the market facing 6 | proposition, from positioning through to messaging and will interface directly 7 | with the broader commercial team and directly with the market place to build the 8 | product profile and ultimately generate demand. 9 | 10 | ## Responsibilities 11 | - Maintain a deep understanding of and insight into the competitive landscape 12 | - Build GTM messaging 13 | - Interface and educate the broader commercial team 14 | - Build a pipeline of opportunity 15 | - Feedback insight to the Product Owner 16 | 17 | ## Communication 18 | The Product Owner has two key stakeholder sets for communication: 19 | 20 | ### Internal 21 | * *Go To Market:* Provide regular and consitent updates to the broader 22 | commercial team 23 | * *Professional Services & Support:* Create, distribute and empower and educate 24 | professional services and support teams on key aspects of the product 25 | * *Product Management:* [Report](#reporting) regular updates, insights and 26 | feedback from the marketplace 27 | 28 | ### External 29 | * *Customers:* Maintain a regular cadence with customers to inform of product 30 | updates, roadmap and broader educational material 31 | 32 | ## Reporting 33 | All Product Marketing Managers report directly into the [Product Owner](../product-owner). 34 | -------------------------------------------------------------------------------- /product-org/roles/product-owner.md: -------------------------------------------------------------------------------- 1 | # Product Owner 2 | The Product Owner is a key stakeholder and ultimate guardian of the product 3 | which they own. They are deeply embedded in all aspects of the product and 4 | empowered to steer product roadmaps and build the supporting team to be 5 | successful. 6 | 7 | ## Responsibilities 8 | Our Product Owners take full responsibility for all elements associated with the 9 | product lifecycle through ideation to delivery. Our Product Owners equally hold 10 | fiduciary duties including budgets for headcount and marketing as well as 11 | regulatory, legal and compliance obligations. 12 | 13 | ### Define The Vision 14 | Based on a deep understanding of the industry and lead by customer intimacy, the 15 | Product Owner is responsible for defining, validating and communication the 16 | vision for the product. 17 | 18 | The product vision will act as the soundboard for all future decisions around 19 | roadmap and feature delivery. 20 | 21 | ### Prioritise 22 | Prioritisation is the single most important responsibilty after the vision has 23 | been established. Our Product Owners must factor in all competing priorities 24 | and contstraints including budgets, customer needs, industry trends and 25 | infrastructure or technical requirements. 26 | 27 | ### Manage The Agile Process 28 | We deliver projects in line with the Agile methodology. 29 | 30 | To help ensure all focus remains on delivering the vision and solving the 31 | identified problem set, an effective Product Owner will manage all Agile 32 | processes including backlog grooming, daily standups, sprint planning and 33 | retrospectives. 34 | 35 | ### Hands on Through Delivery 36 | Our Product Owners build close working relationship with the engineering teams 37 | and will be hands on through the delivery cycles. They are always on hand to 38 | help make critical decisions about functionality and implementation detail. 39 | 40 | ### Obssess About Detail 41 | The product organisation is laser focused on detail. Product Owners will mirror 42 | this obsession to all aspects of the product they own. 43 | 44 | ## Communication 45 | The Product Owner has two key stakeholder sets for communication: 46 | 47 | ### Internal 48 | * *Delivery Teams:* Articulte the vision to the engineering and delivery team 49 | * *Go To Market:* Provide regular and consitent updates to the marketing and 50 | sales organisations 51 | * *Professional Services & Support:* Create, distribute and empower and educate 52 | professional services and support teams on key aspects of the product 53 | * *Product Management:* [Report](#reporting) key updates on functional and 54 | commercial progress 55 | 56 | ### External 57 | * *Customers:* Maintain a regular cadence with customers to inform of product 58 | updates, roadmap and broader educational material 59 | * *Regulatory Bodies:* Inform appropriate regulatory bodies of applicable 60 | changes and impacts 61 | 62 | ## Reporting 63 | All Product Owners report directly into the Senior Vice President (SVP) of 64 | Product. 65 | 66 | At a minimum, Product Owners must submit a monthly report using the following 67 | [form](https://forms.gle/1X5qZj9mKnVb3PoE8). 68 | 69 | -------------------------------------------------------------------------------- /scripts/README.md: -------------------------------------------------------------------------------- 1 | # DVELP Scripts 2 | 3 | A collection of shell scripts that we use at DVELP for our making the everyday more efficient. 4 | 5 | # Heroku Sync DB to Local 6 | 7 | Get it: [heroku\_sync_db_to_local.sh](https://github.com/DVELP/cookbook/blob/master/scripts/heroku_sync_db_to_local.sh) 8 | 9 | Back-up and sync your remote DB to your local machine. 10 | 11 | * Requires two parameters: app_name and local_db_name 12 | 13 | Example: 14 | ``` 15 | heroku_sync_db_to_local.sh my-app my_app_db 16 | ``` 17 | 18 | Alias: 19 | ``` 20 | hdbsync = heroku_sync_db_to_local.sh 21 | ``` 22 | 23 | Todo: 24 | * Pass parameter to skip back-up 25 | * Default app name to current path 26 | 27 | # Heroku Remotes 28 | 29 | Get it: [git\_heroku\_add.sh](https://github.com/DVELP/cookbook/blob/master/scripts/git_heroku_add.sh) 30 | 31 | Quickly setup heroku remotes for deploying to pipeline apps. 32 | 33 | * Requires two parameters: remote_name and heroku_app_name 34 | 35 | Example: 36 | ``` 37 | git_heroku_add.sh staging dvelp-staging 38 | ``` 39 | 40 | Alias: 41 | ``` 42 | har = git_heroku_add.sh 43 | ``` 44 | 45 | # Merging Pull Requests 46 | 47 | Get it: [git\_merge\_pull\_request.sh](https://github.com/DVELP/cookbook/blob/master/scripts/git_merge_pull_request.sh) 48 | 49 | Close pull-requests, merge and clean-up branches with ease. 50 | 51 | * Requires current git branch to be the branch you want to merge to master 52 | * Takes no parameters 53 | 54 | Example: 55 | ``` 56 | git_merge_pull_request.sh 57 | ``` 58 | 59 | Alias: 60 | ``` 61 | gm pr = git_merge_pull_request.sh 62 | ``` 63 | 64 | # Shopify 65 | 66 | Get them: 67 | * Grunt config: [config.yml](shopify/config.yml) 68 | * Gruntfile: [config.yml](shopify/confile.js) 69 | 70 | Developing and deploying to Shopify with ease! Read more [here](../guides/Shopify.md). 71 | 72 | Example: 73 | ``` 74 | grunt deploy 75 | ``` 76 | -------------------------------------------------------------------------------- /scripts/git_heroku_add.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash -e 2 | 3 | git remote add $1 https://git.heroku.com/$2.git 4 | -------------------------------------------------------------------------------- /scripts/git_merge_pull_request.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash -e 2 | 3 | feature_branch=`git symbolic-ref HEAD` 4 | feature_branch=${feature_branch##refs/heads/} 5 | target_branch='master' 6 | verbose='false' 7 | 8 | while getopts 'b:' flag; do 9 | case "${flag}" in 10 | b) target_branch=${OPTARG} ;; 11 | v) verbose='true' ;; 12 | *) error "Unexpected option ${flag}" ;; 13 | esac 14 | done 15 | 16 | if [ "$feature_branch" == $target_branch ]; then 17 | echo "You're on $target_branch branch, checkout feature branch you want to merge" 18 | exit 1 19 | fi 20 | 21 | echo "git fetch origin" 22 | git fetch origin 23 | 24 | echo "git rebase origin/${target_branch}" 25 | git rebase origin/$target_branch 26 | 27 | echo "git push -f" 28 | git push -f 29 | 30 | echo "git checkout ${target_branch}" 31 | git checkout $target_branch 32 | 33 | echo "git merge $feature_branch" 34 | git merge $feature_branch 35 | 36 | echo "git push" 37 | git push 38 | 39 | echo "git push origin --delete $feature_branch" 40 | git push origin --delete $feature_branch 41 | 42 | echo "git branch -d $feature_branch" 43 | git branch -d $feature_branch 44 | 45 | echo "$feature_branch has been merged into ${target_branch}. All is well!" 46 | -------------------------------------------------------------------------------- /scripts/heroku_sync_config.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | set -e 4 | 5 | sourceApp="$1" 6 | targetApp="$2" 7 | defaultKeys=(DATABASE_URL REDISTOGO_URL SENDGRID_PASSWORD SENDGRID_USERNAME) 8 | 9 | while read key value; do 10 | key=${key%%:} 11 | if [[ ${defaultKeys[*]} =~ $key ]]; 12 | then 13 | echo "Ignoring $key=$value" 14 | else 15 | echo "Setting $key=$value" 16 | heroku config:set "$key=$value" --app "$targetApp" 17 | fi 18 | done < <(heroku config --app "$sourceApp" | sed -e '1d') 19 | -------------------------------------------------------------------------------- /scripts/heroku_sync_db_to_local.sh: -------------------------------------------------------------------------------- 1 | #!/bin/zsh 2 | # Script for syncing remote DB to local 3 | 4 | APP_NAME=$1 5 | DB_NAME=$2 6 | DUMP_FILE='latest_backup.dump' 7 | 8 | if [ -n "$APP_NAME" ] && [ -n "$DB_NAME" ]; then 9 | 10 | # Create new backup 11 | echo "Creating backup for $APP_NAME..." 12 | heroku pg:backups capture --app $APP_NAME 13 | wait 14 | 15 | # Fetch the dump from remote 16 | echo "Fetching backup for $APP_NAME..." 17 | curl -o $DUMP_FILE `heroku pg:backups public-url -a $APP_NAME` 18 | wait 19 | 20 | # Restore the local DB from dump 21 | echo "Restoring local DB $DB_NAME..." 22 | pg_restore --verbose --clean --no-acl --no-owner -h localhost -d $DB_NAME $DUMP_FILE 23 | 24 | # Delete local .dump 25 | echo 'Cleaning up...' 26 | rm $DUMP_FILE 27 | else 28 | echo 'You must specify an app and local DB name.' 29 | fi 30 | -------------------------------------------------------------------------------- /scripts/shopify/.gitignore: -------------------------------------------------------------------------------- 1 | # Assets 2 | assets/*.jpg 3 | assets/*.ico 4 | assets/*.png 5 | assets/application.css 6 | assets/application.js 7 | assets/postcss/* 8 | snippets/svgs.liquid 9 | 10 | # Settings 11 | config/settings_data.json 12 | config.yml 13 | -------------------------------------------------------------------------------- /scripts/shopify/circle.yml: -------------------------------------------------------------------------------- 1 | --- 2 | version: 2 3 | jobs: 4 | build: 5 | working_directory: ~/your-app-name 6 | docker: 7 | - image: circleci/ruby:2.5.1-node-browsers 8 | environment: 9 | RAILS_ENV: test 10 | RACK_ENV: test 11 | 12 | - image: circleci/postgres:9.6.2-alpine 13 | environment: 14 | POSTGRES_USER: postgres 15 | POSTGRES_DB: dopay-payengine_test 16 | 17 | steps: 18 | - checkout 19 | 20 | - run: 21 | name: Create environment variables file 22 | command: | 23 | cp config/examples/application.yml config/application.yml 24 | 25 | - restore_cache: 26 | keys: 27 | - v1-dependencies-{{ checksum "Gemfile.lock" }} 28 | - v1-dependencies- 29 | 30 | - run: 31 | name: Install dependencies 32 | command: | 33 | bundle install --jobs=4 --retry=3 --path vendor/bundle 34 | 35 | - save_cache: 36 | paths: 37 | - ./vendor/bundle 38 | key: v1-dependencies-{{ checksum "Gemfile.lock" }} 39 | 40 | - run: 41 | name: Wait for DB 42 | command: dockerize -wait tcp://localhost:5432 -timeout 1m 43 | 44 | - run: 45 | name: Database setup 46 | environment: 47 | DATABASE_URL: 'postgres://postgres@localhost:5432/dopay-payengine_test' 48 | command: | 49 | bundle exec rake db:create db:schema:load --trace 50 | bundle exec rake db:migrate 51 | 52 | - run: 53 | name: Rubocop 54 | command: bundle exec rubocop 55 | 56 | - run: 57 | name: run tests 58 | environment: 59 | DATABASE_URL: 'postgres://postgres@localhost:5432/test_database_name' 60 | command: | 61 | mkdir /tmp/test-results 62 | bundle exec rspec spec --format progress 63 | 64 | -------------------------------------------------------------------------------- /scripts/shopify/config.yml: -------------------------------------------------------------------------------- 1 | --- 2 | :api_key: 'API Key' 3 | :password: 'Password' 4 | :store: 'Shopify store ID' 5 | :theme_id: 'Theme ID' 6 | :ignore_files: 7 | - assets/javascripts/ 8 | - assets/images/ 9 | - assets/sass/ 10 | - config/settings_data.json 11 | - node_modules 12 | -------------------------------------------------------------------------------- /scripts/tmux-session-switch.sh: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env zsh 2 | set -e 3 | 4 | if [[ -z $1 ]]; then 5 | tmux switch-client -l 6 | else 7 | if tmux has-session -t "$1" 2>/dev/null; then 8 | [[ -z "$TMUX" ]] && tmux attach -t "$1" || tmux switch-client -t "$1" 9 | else 10 | if [[ -z "$TMUX" ]]; then 11 | tmux attach -t "$1" 12 | else 13 | TMUX=`tmux new-session -d -s "$1"` 14 | tmux switch-client -t "$1" 15 | fi 16 | fi 17 | fi 18 | 19 | --------------------------------------------------------------------------------