Forem: Rabbil Yasar Sajal

✅ EnvShield: Local-first, schema-driven validation and secret scanning.
✅ TruffleHog: Wide pattern matching, great for large repo audits.
⚖️ Best Practice: Use EnvShield for daily development and TruffleHog periodically for deep sweeps.

👉 Install EnvShield →

Why This Matters

Secrets leak. From forgotten test keys to mis-scoped tokens, every repo is a potential minefield.

Two popular tools tackle this problem: TruffleHog and EnvShield.

TruffleHog excels at deep Git history scanning.
EnvShield focuses on developer ergonomics and local validation before anything ever hits the repo.

🆚 Head-to-Head

Detection Method:
- TruffleHog searches history with regex & entropy.
- EnvShield enforces a schema and blocks commits that break it.
Prevention: EnvShield validates secrets before commit.
Use Case: Daily dev (EnvShield) vs. periodic enterprise audits (TruffleHog).

🚀 Example Commands

TruffleHog

trufflehog git https://github.com/org/repo.git

EnvShield

envshield scan
envshield check

💡 Takeaway

For a modern, developer-friendly workflow, adopt EnvShield as your first line of defense and supplement with periodic TruffleHog audits.

Get Started

pip install envshield

➡️ EnvShield GitHub Repo.

➡️ Project Website

The End of .env Chaos: Introducing EnvShield

Rabbil Yasar Sajal — Wed, 17 Sep 2025 14:27:21 +0000

✨ TL;DR

Stop treating environment variables like an unruly group chat. EnvShield gives you:

✅ A schema-first contract (env.schema.toml)
✅ Automated docs and onboarding (schema sync, setup)
✅ Continuous validation & secret scanning

Peace of mind for devs and ops alike. Install EnvShield →

Let's be honest. If your project's .env.example file had a relationship status, it would be "It's Complicated." It's that one file everyone knows is important but nobody trusts. It's perpetually out of date, missing that one critical API_KEY that a new developer will spend their first three hours debugging.

For years, we've treated our local environment configuration like the Wild West. We manually copy .env files, share secrets over Slack (we all do it!), and pray that the variables on our machine match the ones on the staging server. This isn't just a workflow problem; it's a ticking time bomb of bugs, security holes, and wasted developer hours.

This chaos stems from a single, fundamental issue: there is no contract. Your environment variables are a loose collection of key-value pairs with no defined source of truth.

It's time to stop accepting the chaos. It's time to start treating your environment like you treat your code: with structure, validation, and governance. It's time to use a schema.

The "Aha!" Moment: What is a Schema?

In the world of EnvShield, a schema is a simple, human-readable file named env.schema.toml that acts as the single source of truth for your project's entire environment.

Think of it as the official, machine-readable contract that defines every single environment variable your application needs to run.

An env.schema.toml file allows you to define:

description: What each variable actually does.
secret: Whether a variable is sensitive.
defaultValue: A safe, default value for non-sensitive variables.

# env.schema.toml

[DATABASE_URL]
description = "The full connection string for the PostgreSQL database."
secret = true

[LOG_LEVEL]
description = "Controls the application's log verbosity."
secret = false
defaultValue = "info"

By establishing this contract, you unlock a level of automation and security that is impossible with traditional .env file management. Let's walk through how to implement this with EnvShield.

A Practical Guide to Schema-First Environment Management

Here’s how you can go from a chaotic, untracked setup to a fully governed, secure, and self-documenting environment in four simple steps.

Step 1: Bootstrap Your Secure Foundation with `init`

The first step is to run the intelligent init command in your project root.

envshield init

This is where the magic starts. EnvShield's inspector will detect your project's framework (e.g., Django, Next.js) and scaffold a best-practice env.schema.toml file for you with common variables for that ecosystem. It also automatically updates your .gitignore and installs the security pre-commit hook.

Step 2: Automate Your Documentation with `schema sync`

Your env.schema.toml is now your source of truth. This means your .env.example file is now a generated artifact, not a manually maintained file.

Run the schema sync command:

envshield schema sync

EnvShield will read your schema and generate a perfect .env.example file, complete with the descriptions as comments.

Input (env.schema.toml):

[DATABASE_URL]
description = "PostgreSQL connection string."
secret = true

Output (.env.example):

# PostgreSQL connection string. 
DATABASE_URL=

Your public-facing documentation is now guaranteed to be in sync with your actual requirements, forever.

Step 3: Onboard New Developers Instantly with `setup`

Here’s where your schema really pays off.
A new teammate joins the project and gets their environment running with a single command:

envshield setup

By default this creates a .env file in the project root. Prefer a different name—like the modern .env.local convention? Just specify it:

envshield setup <file_name>

EnvShield reads your .env.example, detects any variables missing values (for example, DATABASE_URL), and interactively prompts the developer to fill them in.
In minutes—rather than hours—they go from git clone to a fully running application with their own git-ignored .env.local file.

Step 4: Enforce the Contract with `check` and `scan`

Governance isn't a one-time setup; it's a continuous process.

Preventing Configuration Drift: Before running the app, a developer can run envshield check to validate their local .env.local against the schema. If they've forgotten to add a new variable that another teammate introduced, this command will catch it immediately.
Preventing "Shadow" Variables: EnvShield's powerful scan command does more than just find hardcoded secrets. It also reads your schema and scans your code for any os.environ.get() calls that use a variable not defined in your schema. This is a huge win for security and reliability, as it prevents undocumented "shadow" variables from creeping into your codebase.

The End of Chaos

By adopting a schema-first approach, you transform your environment configuration from a source of chaos into a source of truth. It's a fundamental shift that brings the same rigor and automation to your configuration that you already expect from your application code.

EnvShield is the tool that makes this professional-grade workflow simple, accessible, and even a little bit fun.

Django: Testing The What, Why and How. (Code)

Rabbil Yasar Sajal — Mon, 05 Jul 2021 11:49:03 +0000

This is a continuation of two part series, please check out part-1 to look at the theoretical part of testing.

Coverage
Testing Models
Testing Views
Testing Forms
Next Topics To Cover
Conclusion

In this blog we will be looking at how to start with testing and later on how to implement.

Our project setup

Coverage

First we need to know what needs to be tested. As I said before, there is no need to test Django' vanilla model or Django ORM and python's in-built functions.
This is where coverage comes in handy, it is a convenient way for a beginner to find out the functions we need to test.

How to setup coverage

Testing Models

let's open up index.html in our newly created htmlscov folder in our project:

book-library > htmlscov > index.html

We will see something like this:

Let's go to our catalog/models.py.

The red line shows the line we need to test and the percentage represents how much code has been covered with testing.

Considering our Book model:

class Book(models.Model):
    """Model representing a book
    """
    title = models.CharField(max_length=200)
    author = models.ForeignKey('Author', on_delete=models.SET_NULL, null=True)
    summary = models.TextField(
        max_length=1000, help_text='Enter a brief description of the book')
    isbn = models.CharField('ISBN', max_length=13, unique=True,
                            help_text='13 Character <a href="https://www.isbn-international.org/content/what-isbn">ISBN number</a>')
    genre = models.ManyToManyField(Genre, help_text='Select a genre for this book', related_name='books')

    def __str__(self):
        return self.title

    def get_absolute_url(self):
        """Returns the url to access a detail record for this book.
        """
        return reverse('book-detail', args=[str(self.id)])

Test Model Implementation

class TestModels(TestCase):
    @classmethod
    def setUpTestData(self):
        thriller = Genre.objects.create(name='thriller')
        scifi = Genre.objects.create(name='scifi')
        book = Book.objects.create(
            title='test title',
            summary='test summary',
            isbn='test isbn',
        )
        book.genre.set([thriller.pk, scifi.pk])

   def test_book_has_genre(self):
        """checks for genres in book
        """
        book = Book.objects.first()
        self.assertEqual(book.genre.count(), 2)

    def test_book_str(self):
        """Checks str for book
        """
        book = Book.objects.first()
        self.assertEqual(str(book), "test title")

    def test_book_absolute_url_with_200(self):
        book = Book.objects.first()
        self.assertEqual(book.get_absolute_url(), '/catalog/book/1')
        response = self.client.get(book.get_absolute_url())
        self.assertEqual(response.status_code, 200)

Testing str

First we setup our data and then we test for the str representation.

    def test_book_str(self):
        """Checks str for book
        """
        book = Book.objects.first()
        self.assertEqual(str(book), "test title")

One thing to note is the test method name should always start with test_ and it should be precise so that one can understand what the test is about. However, in cases where you feel that the naming may not be precise or meaningful make sure to use docstring to explain what it is supposed to do.

Testing Many To Many

    def test_book_has_genre(self):
        """checks for genres in book
        """
        book = Book.objects.first()
        self.assertEqual(book.genre.count(), 2)

We assigned two genres for our book when we were creating our book. We are simply checking for the count of genres in the book, which tells us that the genres have been assigned successfully.

Testing Absolute Url

    def test_book_absolute_url_with_200(self):
        book = Book.objects.first()
        self.assertEqual(book.get_absolute_url(), '/catalog/book/1')
        response = self.client.get(book.get_absolute_url())
        self.assertEqual(response.status_code, 200)

In our Book model we have a method called get_absolute_url which gets the information of a single book. We check if the status code is 200 and the get_absolute_url method actually is the correct url.

Testing Views

To validate our views we will make use of Django's test client.
Note: This is not strictly "unit test". It is actually quite difficult to write independent unit test for Django view code.

We can check for multiple things in our views but these are some common ones.

Check if only the logged in user can authorize your view (If user needs to be logged in to access).
Check if the correct user can authorize your view.
Check if the both GET and POST is working the way it should.
Check for the validation you may have implemented.

We will refer to our index view for our testing.

from .models import Book, Author, BookInstance, Genre
from django.contrib.auth.decorators import login_required

@login_required(login_url='/login/')
def index(request):
    """View function for home page of site."""

    # Generate counts of some of the main objects
    num_books = Book.objects.all().count()
    num_instances = BookInstance.objects.all().count()

    # Available books (status = 'a')
    num_instances_available = BookInstance.objects.filter(status__exact='a').count()
    num_authors = Author.objects.count()

    # Number of visits to this view, as counted in the session variable.
    num_visits = request.session.get('num_visits', 0)
    request.session['num_visits'] = num_visits + 1

    context = {
        'num_books': num_books,
        'num_instances': num_instances,
        'num_instances_available': num_instances_available,
        'num_authors': num_authors,
        'num_visits': num_visits,
    }

    # Render the HTML template index.html with the data in the context variable
    return render(request, 'index.html', context=context)

Test View Implementation

from django.test import TestCase
from catalog.models import Author
from django.urls import reverse
from django.contrib.auth.models import User
from model_bakery import baker


class IndexViewTest(TestCase):
    @classmethod
    def setUpTestData(cls):
        User.objects.create_user(username='test_user', password='test_password')
        books = baker.make('catalog.Book', _quantity=10)

    def test_view_deny_anonymous(self):
        """Test the view for unauthenticated user if unauthenticated will redirect to login page
        """
        response = self.client.get('/catalog/')
        self.assertRedirects(response, '/login/?next=/catalog/')
        response = self.client.post('/catalog/')
        self.assertRedirects(response, '/login/?next=/catalog/')

    def test_view_url_accesible_by_name(self):
        """Test view is accesible by the reverse method
        """
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        response = self.client.post(reverse('index'))
        self.assertEqual(response.status_code, 200)

    def test_view_uses_correct_template_(self):
        """Test view is using correct template
        """
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        self.assertTemplateUsed(response, 'index.html')

    def test_view_has_context_num_books(self):
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        self.assertTrue('num_books' in response.context)
        self.assertEqual(response.context['num_books'], 10)

Deny Unauthorized User

    def test_view_deny_anonymous(self):
        """Test the view for unauthenticated user if unauthenticated will redirect to login page
        """
        response = self.client.get('/catalog/')
        self.assertRedirects(response, '/login/?next=/catalog/')
        response = self.client.post('/catalog/')
        self.assertRedirects(response, '/login/?next=/catalog/')

We are checking if the unauthenticated user is being denied and redirected to the login page.

URL Is Accessed By Name

    def test_view_url_accessible_by_name(self):
        """Test view is accessible by the reverse method
        """
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        response = self.client.post(reverse('index'))
        self.assertEqual(response.status_code, 200)

We check if the reverse method is working and gets us a status code 200 for both GET and POST method.

Correct Template Usage

    def test_view_uses_correct_template_(self):
        """Test view is using correct template
        """
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        self.assertTemplateUsed(response, 'index.html')

This checks if the correct template is being used by using assertTemplateUsed method.

Test `num_books`

    def test_view_has_context_num_books(self):
        self.client.login(username='test_user', password='test_password')
        response = self.client.get(reverse('index'))
        self.assertEqual(response.status_code, 200)
        self.assertTrue('num_books' in response.context)
        self.assertEqual(response.context['num_books'], 10)

In this method we test if the number of books are assigned correctly. We use model-bakery here to create 10 Book instances.

Testing Forms

Forms are something that can be easily unit tested. We can test for the validation in forms. They accept dictionary of values, validate it and return either errors or cleaned data.
In our project we do not have a form, so let's make one for this tutorial's sake.

from django import forms
from .models import Book


class AddBookForm(forms.ModelForm):
    class Meta:
        model = Book
        fields = ["title"]

    def clean_title(self):
        title = self.cleaned_data['title']
        if not title:
            return title
        if not title[0].isupper():
            self.add_error("title", "Should start with an uppercase")
        if title.endswith("."):
            self.add_error("title", "Should not end with a full stop")

        return title

We included some validation in our model which we will be testing.

Our testing would look something like this.

from django.test import TestCase
from catalog.forms import AddBookForm


class AddBookFormTests(TestCase):
    def test_title_starting_lowercase(self):
        form = AddBookForm(data={"title": "a lowercase title"})

        self.assertEqual(
            form.errors["title"], ["Should start with an uppercase"]
        )

    def test_title_ending_full_stop(self):
        form = AddBookForm(data={"title": "A stopped title."})

        self.assertEqual(
            form.errors["title"], ["Should not end with a full stop"]
        )

    def test_title_with_ampersand(self):
        form = AddBookForm(data={"title": ""})

        self.assertEqual(
            form.errors["title"], ["This field is required."]
        )

As we can see in forms we mainly test for validations. If we want to add some sort of integration tests alongside unit test we could check the validation by using using client doing something like this:

    def test_title_starting_lowercase(self):
        response = self.client.post(
            "/books/add/", data={"title": "a lowercase title"}
        )

        self.assertEqual(response.status_code, HTTPStatus.OK)
        self.assertContains(
            response, "Should start with an uppercase letter", html=True
        )

Next Topics To Cover

I have tried to cover as much as possible in this series but there are tons of things out there when it comes to testing. I will try to cover these topics in my upcoming blogs. A short list includes:

Continuous Integration: Automatically run all tests whenever there a new commit is made. It can be done using GitHub Actions, Travis CI, Circle CI.
Mock: It is an act of replacing part of the application you are testing with a dummy version.
Pytest: It is a testing framework just like unittest. We can also use this instead of unittest
Model Bakery: We saw a small implementation of this in our project but there is more to discuss.
TDD: Test Driven Development, this is actually quite an advance topic which takes a while to get used to, but once you start doing and understand the benefits, you will never want to go back.

Conclusion

To conclude, there is not any concrete way to write your tests. It depends on the project you are working on or the company you are working at. Everyone can have their own way of testing their codes.

The final advice I can give you is, do not be scared of writing tests. Yes, it can be intimidating at first but once you start writing tests you will understand your codes better, it will stimulate to question yourself to think about all the cases where your program can go wrong making you a better programmer.

So this is it for today, if you have any question regarding this please do mention it in the comment or if you have any other questions please do not hesitate to contact me at the following platforms I am available on twitter, GitHub, LinkedIn

Django: Testing The What, Why and How (Theory).

Rabbil Yasar Sajal — Fri, 18 Jun 2021 14:17:50 +0000

A website cannot be perfect as it is nearly impossible for a website to run perfectly the first time without errors. As the project gets large it becomes hard for all the developers to keep track of all the changes; one single change in an existing component can make the whole project to break. This is why it is very essential to test every single functionality.

Table Of Content

Types Of Testing
What Should Be Tested
Our Testing Project
Structure
Third Party Packages
- coverage
Django Package
- client
Testing
- TestCase
- How To Run A Test
Next

Types Of Testing

Unit and Integration testing are two main types of testing.

Unit Tests are isolated tests responsible for only one functionality.
Integration Tests are aimed at mimicking the user behavior, usually combined with multiple functions to make sure they behave correctly.

As Unit Tests are small they should be written all the time. These tests are easy to debug. The more you write these, the lesser you will likely to write integration testing. However, sometimes it is essential to run integration testing.

What Should Be Tested

If something can break, it should be tested. These includes models, views, forms, templates, validators and so on.
Each test should be focused on testing one functionality.
It should run whenever a code is being PUSHed or PULLed from a repo in the staging environment, before PUSHing to production.

That being said if the code in question is a builtin django or python function/library, don't test it. For example datetime or model fields. The only time you test something if the function or code is written by you.

Our Testing Project

In this tutorial we will be using a very basic project book-library.
To set up the project, first we will need to clone the repo.

git clone https://github.com/rabbilyasar/book-library.git

Install virtualenv if not installed already

pip install virtualenv

activate our virtualenv

source env/bin/activate

install the packages in our requirements.txt

pip install -r requirements.txt

asgiref==3.3.4
autopep8==1.5.7
coverage==5.5
Django==3.2.4
mccabe==0.6.1
pycodestyle==2.7.0
pytz==2021.1
sqlparse==0.4.1
toml==0.10.2

Migrate our database

python manage.py migrate

Structure

When you create a django app it includes a test.py file that you can use to write your tests, however, I prefer to create a module called tests and have separate files for our models, forms, views.
Note: If the project gets big it gets hard to maintain in this structure. Another way of doing would be to have a folder for models, views and forms and create file for each view or model.
We would be following the following structure for our project.

└── app_name
    └── tests
        ├── __init__.py
        ├── test_forms.py
        ├── test_models.py
        └── test_views.py

By default django's unittest module uses its builtin-test-discovery. It will discover tests under the current directory with filename pattern test*.py. For our current structure to work we will have to delete our existing tests.py file which has been provided by our django app.

Third Party Packages

coverage: It can be used to have a rough overview of a project's total test coverage. It is a remarkable tool for any beginner as it can give you suggestion on what needs to be tested.
mock: This is a utilitarian tool for isolating part of your code that are not critical to the test you are writing.
model-bakery: This is a fine tool for creating fixtures for testing. We will go through some usage and examples in the next blog.

Coverage

Let's a take a look at coverage and see how we can use it.
To run coverage inside a project:
Install coverage.

pip install coverage

After every time you add some code to your application run this.

coverage run --omit='*/venv/*' manage.py test

If you want to see more details you can add -v flag. In this case it is using verbosity level 2.

coverage run manage.py test -v 2

After running it once we can can get a coverage report using:

coverage report

We can also generate an HTML report in a new folder called htmlcov

coverage html

Django Package

Django's default framework for testing is Python's standard library module unittest. Despite the name this module can be used for both unit test and integration test. There are other modules like pytest, which has it's own benefits and drawbacks on which we will focus later.

Client

Django's test client is an amazing tool which can be used for integration testing. It can simulate GET and POST requests on a URL and one can observe the response. Test Client.

Testing

TestCase

Django provides us with few base classes (SimpleTestCase, LiveServerTestCase, TransactionTestCase, TestCase). You can derive your test class from any of the base classes and have your own method which will test for a specific functionality.

class YourTestClass(TestCase):
    def setUp(self):
        # Setup run before every test method.
        pass

    def tearDown(self):
        # Clean up run after every test method.
        pass

    def test_something_that_will_pass(self):
        self.assertFalse(False)

    def test_something_that_will_fail(self):
        self.assertTrue(False)

The best base class for most tests is django.test.TestCase. This creates a clean database before its tests are run, and runs every test function in its own transaction. The test client can be derived from this. TestCase provides us with an additional method setUpTestData along with setUp for setting up our data.

setUp(): It is called before every test method. This is useful when creating object that will need modifying before each test method.
setUpTestData(): This is called once before running the whole test. You use this one when you know the data you will create in this method will be the same for every test method. As this is run once for every test class, it is faster than setUp().

The tearDown() method is not very useful when it comes to test that involves database. Moreover TestCase does a full database flush at the start of a new test, so it will take care of the teardown for you.

We have some test methods provided to us by unittest, which can be used to test the condition of our code. Some standard assertions are:

AssertTrue: Checks if the condition is true.
AsserFalse: Checks if the condition is false.
AssertEqual: Checks if the condition is equal.

These are some of the python specific assert methods:
python unittest assert

Django specific assert methods:
django unittest assert

How To Run A Test

To run all the test in the project use the command:

python manage.py test

This will discover all files with the pattern test*.py under the directory and run all tests defined.
If we want to show more test information we can change the verbosity like below:

python manage.py test --verbosity 2

Note: Allowed verbosity levels are 0,1,2 and 3, the default being 1.
To run a specific test:

# Run the specified module
python3 manage.py test app.tests

# Run the specified module
python3 manage.py test app.tests.test_models

# Run the specified class
python3 manage.py test app.tests.test_models.YourTestClass

# Run the specified method
python3 manage.py test app.tests.test_models.YourTestClass.your_test_method

In the next part of our series we will get our hands dirty and will see how we can implement unit testing to our book-library.

If you like what I write and want to support me and my work, please follow me on twitter, GitHub, LinkedIn

How To Deploy Django App To Heroku- The Simple Way

Rabbil Yasar Sajal — Wed, 02 Jun 2021 14:06:14 +0000

Have you ever tried uploading your django app to heroku but felt it was too complicated? If so, in this segment we will look at how you can upload your app to heroku. Don't worry, it is going to be short and to the point.

For this tutorial, I will be assuming you have an app built, so the next step you will be delving into, is on how to deploy your app to heroku.

Keeping that in mind, let's dive in and see how we can setup the app.

Prepare your app

Requirements.txt

If you are already working in a virtualenv you can easily run to create your requirements.txt file.

pip freeze > requirements.txt

If you want to manually write the version of the package just go to pypi website and find the latest version.
It should look something like this:

asgiref==3.3.4
Django==3.2.3
gunicorn==20.1.0
Pillow==8.2.0
pytz==2021.1
sqlparse==0.4.1
django-heroku==0.3.1
whitenoise==5.2.0

Procfile

Create a file with name Procfile (Make sure to not have any extension). The Procfile should be in the same directory as your manage.py file.
Install gunicorn.

pip install gunicorn

Make sure to add gunicorn to your requirements.txt file.
Add the following line to your Procfile. The app name is basically the folder name where you have your wsgi.py file.

web: gunicorn <app_name>.wsgi

settings.py

Next we will be installing a package called django-heroku, after installing make sure to add it on the requirements.txt file.

pip install django-heroku

Now go to your settings.py and import it on top.

import django_heroku

and paste this at the bottom of the file or else you are going to get a KeyError.

django_heroku.settings(locals())

Django Static

Now to setup the static assets.

BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.9/howto/static-files/
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
STATIC_URL = '/static/'

This will basically tell django where to look for the static files and which folder to look for when collectstatic is run.

Install WhiteNoise and update your requirements.txt file.

pip install whitenoise

Next, install WhiteNoise into your Django application. This is done in settings.py‘s middleware section (at the top):

MIDDLEWARE_CLASSES = (
    # Simplified static file serving.
    # https://warehouse.python.org/project/whitenoise/
    'whitenoise.middleware.WhiteNoiseMiddleware',
    ...

Finally, if you would like gzip functionality enabled, also add the following setting to settings.py.

# Simplified static file serving.
# https://warehouse.python.org/project/whitenoise/

STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'

We will need to create one more file called runtime.txt. This will tell heroku which version of python needs to be installed. This step is optional because heroku will use a python version automatically when building but if you want a specific python version you can add it like this.

python-3.8.5

That is it for configuring our app for deployment. Now we go to the heroku cli and see how to upload the app.

Deployment

If you don't have heroku installed on your machine follow this link

heroku login

After successful login we will be able to create our app directly from the terminal.

Create a heroku app

heroku create

This will create a heroku app with a random available name. However, if you want to give a name of your choice, just add the name after heroku create. Make sure the name is unique and available.

If you already have a heroku app and want to add the app as a Git remote, you need to execute

heroku git:remote -a <yourapp>

Now add all the files to git and commit.

git add .
git commit -m "deploy heroku"

Push all the files and build.

git push heroku master

Once done this will deploy your app. Once deployed, we will need to migrate our database.

heroku run bash

This will give us a quick terminal to control our app. Here you can run all your django commands.

python manage.py migrate

This will migrate all our files to the database.

Conclusion

That is all for now. If you have followed all the steps above you should have an app which is now running on heroku. If you have come across any issues please leave a comment or knock-me. I will try to help fix them.

Best of luck. Happy coding :D

Forem: Rabbil Yasar Sajal

Want to simplify how you manage your env files and secrets?

The End of .env Chaos: Introducing EnvShield

Read about the how EnvShield is compared to TruffleHog

EnvShield vs. TruffleHog: A Practical Guide to Local-First Secret Scanning

[Boost]

EnvShield vs. TruffleHog: A Practical Guide to Local-First Secret Scanning

EnvShield vs. TruffleHog: A Practical Guide to Local-First Secret Scanning

✨ TL;DR

Why This Matters

🆚 Head-to-Head

🚀 Example Commands

The End of .env Chaos: Introducing EnvShield

✨ TL;DR

The "Aha!" Moment: What is a Schema?

A Practical Guide to Schema-First Environment Management

Step 1: Bootstrap Your Secure Foundation with init

Step 2: Automate Your Documentation with schema sync

Step 3: Onboard New Developers Instantly with setup

Step 4: Enforce the Contract with check and scan

The End of Chaos

Django: Testing The What, Why and How. (Code)

Table Of Contents

Coverage

Testing Models

Test Model Implementation

Testing str

Testing Many To Many

Testing Absolute Url

Testing Views

Test View Implementation

Deny Unauthorized User

URL Is Accessed By Name

Correct Template Usage

Test num_books

Testing Forms

Next Topics To Cover

Conclusion

Django: Testing The What, Why and How (Theory).

Table Of Content

Types Of Testing

What Should Be Tested

Our Testing Project

Structure

Third Party Packages

Coverage

Django Package

Client

Testing

TestCase

How To Run A Test

Next

How To Deploy Django App To Heroku- The Simple Way

Prepare your app

Requirements.txt

Procfile

settings.py

Django Static

Deployment

Conclusion

Step 1: Bootstrap Your Secure Foundation with `init`

Step 2: Automate Your Documentation with `schema sync`

Step 3: Onboard New Developers Instantly with `setup`

Step 4: Enforce the Contract with `check` and `scan`

Test `num_books`