Flexibility to deploy on internal network

[jmgate]

I'm leading a small project at the moment where we're trying to stand up a company-internal instance of the Best Practices Badge App. Two questions up front:

1. Is the flexibility to do such a thing desirable for the broader community, such that it'd be worthwhile to build in various toggles to allow one to easily deploy an instance that shouldn't be able to touch the outside internet?
2. Would it be possible to get some assistance with deploying to the production environment, as that seems to involve various environment and database configurations that aren't present in the repository itself?

Motivation

For any of our internal projects that are open-sourced, we heartily recommend using this tool as a means of self-certifying, tracking, and improving on the software engineering practices that surround the development. Unfortunately, most of the software produced at my company will not be released as open source. For all those internal projects, we'd like to provide a version of this tool, hosted internally, so they can realize the same benefits. Most developers wish to do a good job with their work, but they often lack understanding in what that means, and this tool provides significant education to enable and encourage continuous improvement. I imagine the ability to deploy a company-internal version of this tool would be beneficial to employers across the board, particularly if the process was relatively painless.

Brute-Force Changes

Thus far we have been able to:

• fork the project internally,
• create a company-internal branch, containing our changes, to serve as the default branch of our internal fork,
• adjust/remove certain criteria that don't make sense in an internal setting,
• adjust various text around the site for internal use,
• disable the various connections to GitHub, and
• add a few, select, company-specific criteria to a separate section at the end of the passing, silver, and gold levels.

All of the changes have been made in a brute-force manner, but it would be possible to make them more intelligently. E.g., if operating normally, everything behaves as it currently does; if deploying in some sort of internal mode:

• certain text is modified,
• certain operations are switched to no-ops,
• certain functionality is disabled,
• etc.

Instructions (perhaps with associated scripting) could also be provided for establishing company-specific criteria.

Question: Is such flexibility desirable to the upstream project? If not, we'll just stick with the brute-force approach on our end.

Deployment

We've been able to test all our changes thus far by standing up the server in the default development environment. However, when attempting to launch the server in production mode, with

RAILS_ENV=production rails assets:precompile
RAILS_ENV=production rails server

we start running into various issues (I can provide details if you'd like to help troubleshoot). It appears there are likely various environment variables and database configuration settings that are needed for the production environment, but that aren't contained or documented in the repository itself. (Perhaps I just haven't found them yet.)

Question: Would it be possible to get some assistance with deploying to the production environment? Alternatively, might it be sufficient to just run our internal instance in development mode? Are there any potential gotchas in doing so?

[bartlettroscoe]

FYI: This is related to #1635