| Read these guidelines in other languages |
|---|
Thanks for your interest in learning more about how we do DevOps for the platform at freeCodeCamp.org.
We have tried to keep the language in this guide as simple as possible for everyone. However, you may find some technical jargon in here. This is not an exhaustive guide for all operations, and is to be used just as a reference for your understanding of the systems.
We continuously build and deploy master, our default development branch on a separate set of servers.
Typically, the master branch is merged into the production-staging branch once a day and released into an isolated infrastructure. We call this our "staging/beta" application.
It is identical to our live production environment at freeCodeCamp.org, other than it using a separate set of databases, servers, web-proxy, etc. This isolation lets us test ongoing development and features in a "production like" scenario, without affecting regular users of freeCodeCamp.org's platforms.
Once the developer team @freeCodeCamp/dev-team is happy with the changes on the staging application, these changes are moved every few days to the production-current branch. We then release the changes to our live platforms on freeCodeCamp.org
We employ various levels of integration and acceptance testing to check on the quality of the code. All our tests are done through software like Travis and Azure Pipelines. Some of this automated, that is once changes are pushed to the corresponding branch, they get built and deployed on the platforms.
We welcome you to test these releases in a "public beta testing" mode and get early access to upcoming features to the platforms. Sometimes these features/changes are referred to as next, beta, staging, etc. interchangeably.
Your contributions via feedback and issue reports will help us in making the production platforms at freeCodeCamp.org more resilient, consistent and stable for everyone.
We thank you for reporting bugs that you encounter and help in making freeCodeCamp.org better. You rock!
The domain name will be different than freeCodeCamp.org. Currently this public beta testing version is available at:
The dev-team merges changes from the master branch to production-staging when they release changes. Usually the top commit should be what you see live on the site. You can identify the exact version deployed by visiting the build and deployment logs available below in the status section.
The current version of the platform is always available at freeCodeCamp.org.
The dev-team merges changes from the production-staging branch to production-current when they release changes. The top commit should be what you see live on the site. You can identify the exact version deployed by visiting the build and deployment logs available below in the status section.
-
Install Node LTS.
-
Update
npmand install PM2 and setup logrotate and startup on bootnpm i -g npm npm i -g pm2 pm2 install pm2-logrotate pm2 startup -
Clone freeCodeCamp, setup env and keys, install dependencies, and make first build.
npm run ensure-env && npm run build:server -
Start Instances
cd api-server pm2 start production-start.js -i max --max-memory-restart 600M --name org -
Logging, Monitoring and Reloading on updates to code changes
pm2 logspm2 monitorpm2 reload all --update-env && pm2 logs
We use Azure Pipelines and other CI software (Travis, GitHub Actions), to continuously test and deploy our applications.
Currently, only the developer team can push to the production branches, because of the automated deployments on live sites. The changes to the production-* branches can land only via fast-forward merge to the upstream.
Note: In the upcoming days we would improve this flow to be done via pull-requests, for better access management and transparency.
-
Configure your remotes correctly.
freeCodeCamp on master is 📦 v0.0.1 via ⬢ v10.16.0 ❯ git remote -v origin [email protected]:raisedadead/freeCodeCamp.git (fetch) origin [email protected]:raisedadead/freeCodeCamp.git (push) upstream [email protected]:freeCodeCamp/freeCodeCamp.git (fetch) upstream [email protected]:freeCodeCamp/freeCodeCamp.git (push)
-
Make sure your master is pristine and in sync with the upstream.
git checkout master git fetch --all --prune git reset --hard upstream/master
-
Check that the Travis CI is passing on the master branch for upstream.
- https://travis-ci.org/freeCodeCamp/freeCodeCamp/branches should be Green.
-
Confirm that you are able to build the repository locally.
npm run clean-and-develop -
Move changes from master to
production-staginggit checkout production-staging git merge master git push upstreamYou will not be able to force push and if you have re-written the history in anyway these commands will error out.
Once the changes are pushed to the production branches, these should trigger our build and release pipelines:
-
Build Pipeline: https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_build
This pipeline is setup to build artifacts for deployments.
-
Release Pipeline: https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release
This pipeline is setup to deploy artifacts to their destination servers.
The build pipeline triggers the release pipeline after a hold of 15 minutes for our staff developers to go in and intervene if necessary. We would make these to have manual approvals in future for more faster builds.
For now, you should not trigger more than one build within an hour, and wait for a previous build to complete.
The code/config is publicly accessible on Azure's Dev Dashboard. Write access to this is limited to the freeCodeCamp.org staff team.
Note: The release pipeline is intentionally not deploying to production site currently, before the upcoming release. This should change when the guide goes live in a few days.
| Platform | Type | Status |
|---|---|---|
| Travis CI | Unit Tests |  |
| Azure Pipelines | Artifacts |
| Application | Version | Status |
|---|---|---|
| Client | Beta/Next | |
| API | Beta/Next | |
| Client | Production | |
| API | Production |
There will be some known limitations and tradeoffs when using the beta version of the platform.
-
All data / personal progress on these beta applications
will NOT be saved or carried overto production.Users on the beta version will have a separate account from the production. The beta version uses a physically separate database from production. This gives us the ability to prevent any accidental loss of data or modifications. The dev team may purge the database on this beta version as needed.
-
Deployment is expected to be frequent and in rapid iterations, sometimes multiple times a day. As a result there will be unexpected downtime at times or broken functionality on the beta version. The dev team will usually notify for updates in the Contributors Chat room.
-
The beta site is and always has been to augment local development and testing, nothing else. It's not a promise of what’s coming, but a glimpse of what is being worked upon.
-
Google, GitHub and Facebook logins will NOT be available in this beta mode. This is simply a technical limitation, because we are using a separate
test domainfor this version. Email logins will work just as fine.The sign page may look different than production (as a measure to isolate the development and the production databases.)
Please open fresh issues for discussions and reporting bugs. You can label them as release: next/beta for triage.
You may send an email to [email protected] if you have any queries. As always all security vulnerabilities should be reported to [email protected] instead of the public tracker and forum.