fix(migrations): remove features/0060 set environment not null

[gagantrivedi]

Thanks for submitting a PR! Please check the boxes below:

• I have run pre-commit to check linting
• I have filled in the "Changes" section below?
• I have filled in the "How did you test this code" section below?
• I have used a Conventional Commit title for this Pull Request

Changes

Revert 55a9ef7

How did you test this code?

N/A

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 5, 2023 11:48am
flagsmith-frontend-preview	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 5, 2023 11:48am
flagsmith-frontend-staging	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 5, 2023 11:48am

[github-actions]

Uffizzi Preview deployment-35218 was deleted.

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: -0.01% ⚠️

Comparison is base (55a9ef7) 95.48% compared to head (190a077) 95.47%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2738      +/-   ##
==========================================
- Coverage   95.48%   95.47%   -0.01%     
==========================================
  Files         994      993       -1     
  Lines       27939    27909      -30     
==========================================
- Hits        26677    26647      -30     
  Misses       1262     1262              

Files Changed	Coverage Δ
api/app/settings/common.py	87.95% <ø> (ø)
api/features/models.py	93.60% <ø> (ø)
api/tests/unit/features/test_migrations.py	100.00% <ø> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[matthewelwell]

So, I guess there are some considerations here:

1. Should we revert the change from the migration in the staging DB?
2. Should we delete the record in the django_migrations table in the production db?

Since the migration hasn't materially changed the behaviour of the code we can probably get away with doing neither of these, but it might be slightly confusing to see.

I would recommend that we do do both.

[gagantrivedi]

So, I guess there are some considerations here:

1. Should we revert the change from the migration in the staging DB?

2. Should we delete the record in the django_migrations table in the production db?

Since the migration hasn't materially changed the behaviour of the code we can probably get away with doing neither of these, but it might be slightly confusing to see.

I would recommend that we do do both.

Yeah, both would be ideal