DCV-2572 dbt-coves blue-green #482
Conversation
| proc.join() | ||
|
|
||
|
|
||
| # if __name__ == "__main__": |
There was a problem hiding this comment.
Could we avoid keeping this commented out and test this differently?
There was a problem hiding this comment.
@ssassi I agree, it belongs to the code Coldbore sent us, and its testing case. I'd like to discuss how all this should be tested.
dbt_coves/tasks/blue_green/main.py
Outdated
| """ | ||
| green_exists = self._check_if_database_exists() | ||
| if green_exists and self.drop_staging_db: | ||
| if self.drop_staging_db_after: |
There was a problem hiding this comment.
it should also validate that it's a valid int?
There was a problem hiding this comment.
Wouldn't it be caught by the Config class? https://github.com/datacoves/dbt-coves/blob/DCV-2572-implement-blue-green-in-dbt-coves/dbt_coves/config/config.py#L170
dbt_coves/tasks/blue_green/main.py
Outdated
| f"Green database {self.staging_database} exists." | ||
| f"Waiting {self.drop_staging_db_after} minutes before dropping it" | ||
| ) | ||
| for i in range(self.drop_staging_db_after): |
There was a problem hiding this comment.
Shouldn't this raise an exception if the number of loops ended and the database still exists?
There was a problem hiding this comment.
Agree, if you explicitly set it to drop, and give it X minutes to try and drop, something might've happened and blue-green cannot continue
Done.
This PR implements
dbt-coves blue-greencommandIt's basically a reimplementation of Balboa's blue_green_run script, with the main difference here we use pure Python instead of
Python + dbt macrosWARNING: use testing databases like
BRUNO_TEST, as data can be lost during swap/drop.A dbt blue-green run consists of copying a blue (production) database into a green (staging one), making sure dbt builds correctly, swapping them and dropping the old production one.
This process runs the following: