{"database": "pelican", "table": "content", "is_view": false, "human_description_en": "where category = \"technology\" and published_date = \"2021-03-14\"", "rows": [["ryan", "technology", "Integrating a version control system into your development cycle is just kind\nof one of those things that you do, right? I use GutHub for my version\ncontrol, and it\u2019s GitHub Actions to help with my deployment process.\n\nThere are 3 `yaml` files I have to get my local code deployed to my production\nserver:\n\n  * django.yaml\n  * dev.yaml\n  * prod.yaml\n\nEach one serving it\u2019s own purpose\n\n## django.yaml\n\nThe `django.yaml` file is used to run my tests and other actions on a GitHub\nrunner. It does this in 9 distinct steps and one Postgres service.\n\nThe steps are:\n\n  1. Set up Python 3.8 - setting up Python 3.8 on the docker image provided by GitHub\n  2. psycopg2 prerequisites - setting up `psycopg2` to use the Postgres service created\n  3. graphviz prerequisites - setting up the requirements for graphviz which creates an image of the relationships between the various models\n  4. Install dependencies - installs all of my Python package requirements via pip\n  5. Run migrations - runs the migrations for the Django App\n  6. Load Fixtures - loads data into the database\n  7. Lint - runs `black` on my code\n  8. Flake8 - runs `flake8` on my code\n  9. Run Tests - runs all of the tests to ensure they pass\n\n    \n    \n    name: Django CI\n    \n    on:\n      push:\n        branches-ignore:\n          - main\n          - dev\n    \n    jobs:\n    \n      build:\n        runs-on: ubuntu-18.04\n        services:\n          postgres:\n            image: postgres:12.2\n            env:\n              POSTGRES_USER: postgres\n              POSTGRES_PASSWORD: postgres\n              POSTGRES_DB: github_actions\n            ports:\n              - 5432:5432\n            # needed because the postgres container does not provide a healthcheck\n            options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5\n    \n        steps:\n        - uses: actions/checkout@v1\n        - name: Set up Python 3.8\n          uses: actions/setup-python@v1\n          with:\n            python-version: 3.8\n        - uses: actions/cache@v1\n          with:\n            path: ~/.cache/pip\n            key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}\n            restore-keys: |\n              ${{ runner.os }}-pip-\n        - name: psycopg2 prerequisites\n          run: sudo apt-get install python-dev libpq-dev\n        - name: graphviz prerequisites\n          run: sudo apt-get install graphviz libgraphviz-dev pkg-config\n        - name: Install dependencies\n          run: |\n            python -m pip install --upgrade pip\n            pip install psycopg2\n            pip install -r requirements/local.txt\n        - name: Run migrations\n          run: python manage.py migrate\n        - name: Load Fixtures\n          run: |\n            python manage.py loaddata fixtures/User.json\n            python manage.py loaddata fixtures/Sport.json\n            python manage.py loaddata fixtures/League.json\n            python manage.py loaddata fixtures/Conference.json\n            python manage.py loaddata fixtures/Division.json\n            python manage.py loaddata fixtures/Venue.json\n            python manage.py loaddata fixtures/Team.json\n        - name: Lint\n          run: black . --check\n        - name: Flake8\n          uses: cclauss/GitHub-Action-for-Flake8@v0.5.0\n        - name: Run tests\n          run: coverage run -m pytest\n    \n\n## dev.yaml\n\nThe code here does essentially they same thing that is done in the `deploy.sh`\nin my earlier post [Automating the Deployment](/automating-the-\ndeployment.html) except that it pulls code from my `dev` branch on GitHub onto\nthe server. The other difference is that this is on my UAT server, not my\nproduction server, so if something goes off the rails, I don\u2019t hose\nproduction.\n\n    \n    \n    name: Dev CI\n    \n    on:\n      pull_request:\n        branches:\n          - dev\n    \n    jobs:\n      deploy:\n        runs-on: ubuntu-18.04\n        steps:\n          - name: deploy code\n            uses: appleboy/ssh-action@v0.1.2\n            with:\n              host: ${{ secrets.SSH_HOST_TEST }}\n              key: ${{ secrets.SSH_KEY_TEST }}\n              username: ${{ secrets.SSH_USERNAME }}\n    \n              script: |\n                rm -rf StadiaTracker\n                git clone --branch dev git@github.com:ryancheley/StadiaTracker.git\n    \n                source /home/stadiatracker/venv/bin/activate\n    \n                cd /home/stadiatracker/\n    \n                rm -rf /home/stadiatracker/StadiaTracker\n    \n                cp -r /root/StadiaTracker/ /home/stadiatracker/StadiaTracker\n    \n                cp /home/stadiatracker/.env /home/stadiatracker/StadiaTracker/StadiaTracker/.env\n    \n                pip -q install -r /home/stadiatracker/StadiaTracker/requirements.txt\n    \n                python /home/stadiatracker/StadiaTracker/manage.py migrate\n    \n                mkdir /home/stadiatracker/StadiaTracker/static\n                mkdir /home/stadiatracker/StadiaTracker/staticfiles\n    \n                python /home/stadiatracker/StadiaTracker/manage.py collectstatic --noinput -v0\n    \n                systemctl daemon-reload\n                systemctl restart stadiatracker\n    \n\n## prod.yaml\n\nAgain, the code here does essentially they same thing that is done in the\n`deploy.sh` in my earlier post [Automating the Deployment](/automating-the-\ndeployment.html) except that it pulls code from my `main` branch on GitHub\nonto the server.\n\n    \n    \n    name: Prod CI\n    \n    on:\n      pull_request:\n        branches:\n          - main\n    \n    jobs:\n      deploy:\n        runs-on: ubuntu-18.04\n        steps:\n          - name: deploy code\n            uses: appleboy/ssh-action@v0.1.2\n            with:\n              host: ${{ secrets.SSH_HOST }}\n              key: ${{ secrets.SSH_KEY }}\n              username: ${{ secrets.SSH_USERNAME }}\n    \n              script: |\n                rm -rf StadiaTracker\n                git clone git@github.com:ryancheley/StadiaTracker.git\n    \n                source /home/stadiatracker/venv/bin/activate\n    \n                cd /home/stadiatracker/\n    \n                rm -rf /home/stadiatracker/StadiaTracker\n    \n                cp -r /root/StadiaTracker/ /home/stadiatracker/StadiaTracker\n    \n                cp /home/stadiatracker/.env /home/stadiatracker/StadiaTracker/StadiaTracker/.env\n    \n                pip -q install -r /home/stadiatracker/StadiaTracker/requirements.txt\n    \n                python /home/stadiatracker/StadiaTracker/manage.py migrate\n    \n                mkdir /home/stadiatracker/StadiaTracker/static\n                mkdir /home/stadiatracker/StadiaTracker/staticfiles\n    \n                python /home/stadiatracker/StadiaTracker/manage.py collectstatic --noinput -v0\n    \n                systemctl daemon-reload\n                systemctl restart stadiatracker\n    \n\nThe general workflow is:\n\n  1. Create a branch on my local computer with `git switch -c branch_name`\n  2. Push the code changes to GitHub which kicks off the `django.yaml` workflow.\n  3. If everything passes then I do a pull request from `branch_name` into `dev`.\n  4. This kicks off the `dev.yaml` workflow which will update UAT\n  5. I check UAT to make sure that everything works like I expect it to (it almost always does \u2026 and when it doesn\u2019t it\u2019s because I\u2019ve mucked around with a server configuration which is the problem, not my code)\n  6. I do a pull request from `dev` to `main` which updates my production server\n\nMy next enhancement is to kick off the `dev.yaml` process if the tests from\n`django.yaml` all pass, i.e. do an auto merge from `branch_name` to `dev`, but\nI haven\u2019t done that yet.\n\n", "2021-03-14", "enhancements-using-github-actions-to-deploy", "Integrating a version control system into your development cycle is just kind\nof one of those things that you do, right? I use GutHub for my version\ncontrol, and it\u2019s GitHub Actions to help with my deployment process.\n\nThere are 3 `yaml` files I have to get my local \u2026\n\n", "Enhancements: Using GitHub Actions to Deploy", "https://www.ryancheley.com/2021/03/14/enhancements-using-github-actions-to-deploy/"]], "truncated": false, "filtered_table_rows_count": 1, "expanded_columns": [], "expandable_columns": [], "columns": ["author", "category", "content", "published_date", "slug", "summary", "title", "url"], "primary_keys": ["slug"], "units": {}, "query": {"sql": "select author, category, content, published_date, slug, summary, title, url from content where \"category\" = :p0 and \"published_date\" = :p1 order by slug limit 101", "params": {"p0": "technology", "p1": "2021-03-14"}}, "facet_results": {}, "suggested_facets": [{"name": "published_date", "type": "date", "toggle_url": "http://search.ryancheley.com/pelican/content.json?category=technology&published_date=2021-03-14&_facet_date=published_date"}], "next": null, "next_url": null, "private": false, "allow_execute_sql": true, "query_ms": 17.0380137860775}