OpenCRVS
v1.7
v1.7
  • 👋Welcome!
  • CRVS Systems
    • Understanding CRVS
    • Effective digital CRVS systems
    • OpenCRVS within a government systems architecture
    • OpenCRVS Value Proposition
  • Product Specifications
    • Functional Architecture
    • Workflow management
    • Status Flow Diagram
    • User roles & scopes
      • Examples
    • Core functions
      • 1. Notify event
      • 2. Declare event
      • 3. Validate event
      • 4. Register event
      • 5. Print certificate
      • 6. Issue certificate
      • 7. Search for a record
      • 8. View record
      • 9. Correct record
      • 10. Verify record
      • 11. Archive record
      • 12. Vital statistics export
    • Support functions
      • 13. Login
      • 14. Audit
      • 15. Deduplication
      • 16. Performance management
      • 17. Payment
      • 18. Learning
      • 19. User support
      • 20. User onboarding
    • Admin functions
      • 21. User management
      • 22. Comms management
      • 23. Content management
      • 24. Config management
    • Data functions
      • 25. Legacy data import
      • 26. Legacy paper import
  • Technology
    • Architecture
      • Performance tests
    • Standards
      • FHIR Documents
        • Event Composition
        • Person
        • Registration Task
        • Event Observations
        • Locations
    • Security
    • Interoperability
      • Create a client
      • Authenticate a client
      • Event Notification clients
      • Record Search clients
      • Webhook clients
      • National ID client
      • FHIR Location REST API
      • Other ways to interoperate
  • Default configuration
    • Intro to Farajaland
    • Civil registration in Farajaland
    • OpenCRVS configuration in Farajaland
      • Application settings
      • User roles
      • Declaration forms
      • Certified Copies templates
    • Business process flows in Farajaland
  • Setup
    • 1. Planning an OpenCRVS Implementation
    • 2. Establish project and team
    • 3. Gather requirements
      • 3.1 Mapping business processes
      • 3.2 Mapping offices and user types
      • 3.3 Define your application settings
      • 3.4 Designing event declaration forms
      • 3.5 Designing a certified copy
    • 4. Installation
      • 4.1 Quick start: Set-up a local development environment
        • 4.1.1 Install the required dependencies
        • 4.1.2 Install OpenCRVS locally
        • 4.1.3 Starting and stopping OpenCRVS
        • 4.1.4 Log in to OpenCRVS locally
        • 4.1.5 Tooling
          • 4.1.5.1 WSL Support
      • 4.2 Configure: Set-up your own, local, country configuration
        • 4.2.1 Fork your own country configuration repository
        • 4.2.2 Set up administrative address divisions
          • 4.2.2.1 Prepare source file for administrative structure
          • 4.2.2.2 Prepare source file for statistics
        • 4.2.3 Set up CR offices and Health facilities
          • 4.2.3.1 Prepare source file for CRVS Office facilities
          • 4.2.3.2 Prepare source file for health facilities
        • 4.2.4 Set up employee users, and scopes, for testing or production
          • 4.2.3.1 Prepare source file for employees
          • 4.2.3.2 Configure roles and scopes
        • 4.2.5 Set up application settings
          • 4.2.5.1 Managing language content
            • 4.2.5.1.1 Informant and staff notifications
          • 4.2.5.2 Configuring Metabase Dashboards
        • 4.2.6 Configure certificate templates
        • 4.2.7 Configure declaration forms
          • 4.2.7.1 Configuring an event form
        • 4.2.8 Seeding & clearing your local databases
        • 4.2.9 Countryconfig API endpoints explained
      • 4.3 Deploy: Set-up a server-hosted environment
        • 4.3.1 Verify servers & create a "provision" user
        • 4.3.2 TLS / SSL & DNS
          • 4.3.2.1 LetsEncrypt https challenge in development environments
          • 4.3.2.2 LetsEncrypt DNS challenge in production
          • 4.3.2.3 Static TLS certificates
        • 4.3.3 Configure inventory files
        • 4.3.4 Create a Github environment
          • 4.3.4.1 Environment secrets and variables explained
          • 4.3.4.2 VPN Recipes
        • 4.3.5 Provisioning servers
          • 4.3.5.1 SSH access
          • 4.3.5.2 Building, pushing & releasing your countryconfig code
          • 4.3.5.3 Ansible tasks when provisioning
        • 4.3.6 Deploy
          • 4.3.6.1 Running a deployment
          • 4.3.6.2 Seeding a server environment
          • 4.3.6.3 Login to an OpenCRVS server
          • 4.3.6.5 Resetting a server environment
        • 4.3.7 Backup & Restore
          • 4.3.7.1 Restoring a backup
          • 4.3.7.2 Off-boarding from OpenCRVS
    • 5. Quality assurance testing
    • 6. Go-live
      • 6.1 Pre-Deployment Checklist
    • 7. Operational Support
    • 8. Monitoring
      • 8.1 Application logs
      • 8.2 Infrastructure health
      • 8.3 Routine monitoring checklist
      • 8.4 Setting up alerts
      • 8.5 Managing a Docker Swarm
  • General
    • Community
    • Contributing
    • Migration notes
    • Releases and upgrades
    • Release notes
    • Product roadmap
Powered by GitBook
On this page
  1. Setup
  2. 4. Installation
  3. 4.2 Configure: Set-up your own, local, country configuration

4.2.1 Fork your own country configuration repository

Previous4.2 Configure: Set-up your own, local, country configurationNext4.2.2 Set up administrative address divisions

The first step towards configuring your own country configuration of OpenCRVS is to our existing country configuration based on our demonstration country . the following steps help you change the cloned Farajaland repo into your own country configuration fork.

  1. When you ran the bash setup.sh script in step , the country configuration repo for Farajaland was cloned into the same parent directory as opencrvs-core, as you are probably aware. The first thing that you want to do is to change the name of the cloned opencrvs-countryconfig directory to something like "opencrvs-<your country>".

  2. Next, we strongly recommend that you account on Github for storing your country configuration fork so that you can share access amongst your internal team safely.

  3. named the same as your new directory, ie: "opencrvs-<your country>" on your organisation's account on Github.

  4. Copy the Git URL to this repository, e.g. https://github.com/<your organisation>/opencrvs-<your country>.git

  5. In Terminal, cd inside your local directory for the country configuration, opencrvs-<your country>. If you run git remote -v inside this directory you should see that the origin Git URLs are still pointing to our Farajaland repo. We need to point these origin URLs to your repo. To do that, run this command: 

git remote set-url origin git@github.com:<your organisation>/opencrvs-<your country>.git

  1. You can check that the origin URLs have changed successfully by running git remote -v again.

  2. Ensure that you are on the master branch of the country configuration folder: git checkout master

  3. Run git push to push the example Farajaland code to your repo. Once the files are pushed you should see the country configuration code on your own Github repo.

In the above example, a "classic" branch protection rule is being created on the branch "main". The following settings should be checked:

  • Require a pull request before merging / Require approvals

  • Require review from Code Owners Require status checks to pass before merging / Require branches to be up to date before merging

  • Restrict who can push to matching branches

The following should be unchecked:

  • Allow force pushes

  • Allow deletions

When upgrading OpenCRVS

It's up to your team to decide how you wish to manage pulling future release code from our countryconfig / "farajaland" repo. An example strategy is explained below.

  1. Add in our countryconfig repo as a new remote and call it 'upstream'

git remote add upstream git@github.com:opencrvs/opencrvs-countryconfig.git

  1. Maintain a new branch that you use to pull in latest releases. You can use this to review changes in a pull request before fixing conflicts.

// when you are ready to upgrade

git checkout -b upstream-release-v<enter the release number here>
git fetch upstream
git merge upstream/release-v<enter the release number here>

// review conflicts on github
// fix conflicts deploy to QA environments
// merge into your main/master for Staging & Production
// You should be used to using --track to return to checkout develop and main/master
// This is because you may have branches with duplicate names on each remote

We strongly recommend that you set up a branching strategy on your repo to ensure that you can develop features on feature branches, merge them into develop for testing and main or master for releases. Therefore create a companion develop branch that you will use for developing the rest of your configuration: git checkout -b develop & then push that code up to your new repository with git push

It is very important that you configure on your master, develop and main branches as these branches should not be able to be pushed to by any developer without a pull request for code review.

Following best practices, we recommend that you setup so that no developer can push code to your important branches without a pull request

Gitflow
branch protection rules
branch protection rules
fork
Farajaland - Repo: opencrvs-countryconfig
3.1.2 to install OpenCRVS locally
create or use an existing organisation
Create a new, private Git repository