dbt Fusion Python 2026: Rust-engine opas

Päivitetty: 15. syyskuuta 2026

dbt Fusion on dbt Labsin Rustilla kirjoitettu seuraavan sukupolven suorituskonemoottori, joka korvaa Python-pohjaisen dbt Core -kääntäjän ja jäsentää projektit noin 20–30-kertaa nopeammin, tarjoaa staattisen SQL-tyyppitarkistuksen sekä Language Server Protocol (LSP) -tuen VS Codelle. Siihen liittyvä dbt Core v2 tuo saman moottorin avoimen lähdekoodin puolelle ELv2-lisenssin alla. Käytännössä analytiikkainsinöörin arki nopeutuu: dbt parse pipelinessa laskee kymmenistä sekunneista alle sekuntiin, kirjoitusvirheet löytyvät jo editorissa, eikä yön yli ajettu backfill kaadu enää ensimmäiseen tyyppimismatchiin. Tässä oppaassa käydään läpi migraatio dbt Core v1.9:stä Fusioniin ja v2:een, sekä miksi pipeline-testeistä ei kannata tinkiä (kantapään kautta opittu).

dbt Fusion 0.5 (elokuu 2026) on Rust-pohjainen dbt-engine, joka jäsentää projektit 20–30× nopeammin ja tarjoaa staattisen SQL-tyyppitarkistuksen ennen kuin ajat dbt build.
dbt Core v2.0 alpha (heinäkuu 2026) käyttää Fusion-runtimea BSL-vapaana ELv2-lisenssillä; manifest-versio nousee v12:sta v20:aan, ja shim-kerros pitää olemassa olevat pluginit toimivina siirtymäjaksolla.
LSP-tuki VS Codelle antaa määritelmähypyt, virheiden korostuksen ja jinja-autotäydennyksen editorissa, joten dbt compile -silmukkaa ei enää tarvita.
Adapterit Snowflake, BigQuery, Databricks, Postgres ja Redshift ovat Fusion-yhteensopivia GA-tasolla; DuckDB, Trino ja Athena ovat beetassa syyskuussa 2026.
Microbatch-strategia on nyt vakaa (GA v1.9:ssä, säilyy v2:ssa) ja käsittelee inkrementaalisia malleja aikaikkuna kerrallaan, joten backfill ei lataa taulun koko historiaa yhteen erään.
Testejä ei ohiteta: dbt-unit-testit (unit_tests:) ajetaan Fusionin muistissa, ja Great Expectations tai Elementary täydentävät tuotannon data-laadun valvonnan.

Mikä dbt Fusion on ja miksi siitä puhutaan

dbt Fusion on dbt Labsin syyskuussa 2025 julkistama ja elokuussa 2026 versioon 0.5 kypsynyt Rust-pohjainen suorituskoneisto, joka korvaa alkuperäisen Python-kirjoitetun dbt-core-parserin ja kääntäjän. Aiemmin dbt-projekti ajettiin siten, että Python luki models/-hakemiston, jäsensi Jinja-mallit, muodosti riippuvuusgraafin ja lopuksi lähetti renderöidyn SQL:n varastoon. Tuhannen mallin monorepolla tämä pystymatka saattoi kestää 45–90 sekuntia jokaisen komennon alussa. Fusion tekee saman työn keskimäärin 1–3 sekunnissa, koska se hyödyntää Rustin nollakopio-jäsentäjää ja rinnakkaista jinja-evaluointia.

Toinen isompi muutos on staattinen SQL-tyyppitarkistus. Fusion tuntee jokaisen adapterin murrelmat (Snowflake, BigQuery, Databricks, Postgres, Redshift) ja pystyy tarkistamaan sarakkeiden tyypit, olemassaolon ja NULL-turvallisuuden ennen kuin yksikään kysely ajetaan varastossa. Käytännön esimerkkinä: jos kirjoitat vahingossa {{ ref('orders') }}.customer_ide pilkkuvirheellä, Fusion huomauttaa asiasta jo dbt parse -vaiheessa. Ei siis vasta yön backfillissä, kun päivystäjä herää klo 3.14 (kokemuksesta puhuen).

Kolmas asia on Language Server Protocol -tuki. Fusion-binääri toimii samalla dbt-LSP-palvelimena, jonka VS Code -laajennus asentaa ja käynnistää. Editorissa saat välittömän palautteen ref-hypyistä, jinja-syntaksista, testien konfiguraatiosta ja mallien materialisointistrategioista. Aiemmin sama työ tehtiin ajamalla dbt compile silmukassa ja lukemalla stack traceja. Hidasta, ja ergonomisesti aika kuluttavaa.

Fusion on tällä hetkellä avoin lähdekoodi Apache 2.0 -lisenssillä, mikä on iso ero verrattuna aiempaan dbt Cloud IDE:hen, joka oli suljettua. Tämä tarkoittaa, että pienetkin analytiikkatiimit voivat ottaa Fusionin käyttöön ilman dbt Cloud -tilausta, mikäli ne haluavat pelkän runtime-nopeutuksen.

dbt Core v2.0: mikä muuttuu ja mitä hyötyä siitä on

dbt Core v2.0 alpha julkaistiin heinäkuussa 2026, ja se on ensimmäinen dbt Core -versio, jonka runtime on Rust-pohjainen Fusion, ei enää Python-parseri. Kirjoitushetkellä (syyskuu 2026) v2.0 on vielä alpha, mutta dbt Labs on ilmoittanut GA-julkaisusta joulukuulle 2026 (virallinen versio-roadmap).

Konkreettiset muutokset:

Lisenssi vaihtuu BSL:stä ELv2:een. Elastic License 2.0 sallii käytön kaupallisissa projekteissa niin kauan kuin et myy dbt:tä palveluna (SaaS). Käytännössä useimmille tiimeille tämä ei muuta mitään, mutta pilvitarjoajille (kilpailevat dbt Cloudin kanssa) se sulkee oven.
Python-riippuvuudet vähenevät. v2:ssa ei enää tarvita jinja2, agate tai networkx asennuksen mukana, koska Fusion hoitaa ne itse. pip install dbt-core==2.0.0 tuo mukanaan vain ohuen Python-CLI:n, joka kutsuu Rust-binääriä.
manifest.json siirtyy versioon v20. Kaikki metatiedot mallien tyypeistä, testeistä ja lineage-tiedosta ovat mukana; v12-yhteensopivuutta ylläpidetään shim-kerroksella siirtymäjaksolla.
Uusi --defer-state-oletus. CI-ajoissa vain muuttuneet mallit rakennetaan, ja loput katkaistaan tuotannon manifest-tilaan, mikä on noin 60–80 % nopeampi PR-tarkistus keskikokoisissa projekteissa.
Adapter-refaktorointi. Adapterit noudattavat uutta trait-pohjaista rajapintaa, eikä niitä enää ladata Python-pluginina vaan Rust-dylibinä. Yhteisö-adapterit (esim. dbt-duckdb) tarvitsevat päivityksen ennen v2-tukea.

Jos ylläpidät data-alustaa, joka rakentuu vahvasti dbt:n varaan, kannattaa jo nyt tutustua DuckDB Python -analyysioppaaseen alustan kestävyyden näkökulmasta. v2-migraatio on hyvä tilaisuus siivota myös orkestroinnin ja rinnakkaisten työkalujen puolelta ne osat, jotka olisi pitänyt siivota jo aiemmin.

manifest v20 ja yhteensopivuus vanhaan koodiin

manifest.json on dbt-projektin metatietokompilaatti. Se sisältää jokaisen mallin, testin, seedin, snapshotin ja lähteen kuvauksen, dokumentaation ja lineage-graafin. Aiemmin sitä käyttivät esim. Elementary, dbt-osmosis, Metaplane ja Monte Carlo. v20:n muutokset ovat suurimmat sitten v9:n vuonna 2023:

# Vanha (v12):
{
  "metadata": {"dbt_schema_version": "v12"},
  "nodes": {
    "model.jaffle.orders": {
      "database": "analytics",
      "schema": "prod",
      "columns": {
        "order_id": {"data_type": "INTEGER"}
      }
    }
  }
}

# Uusi (v20):
{
  "metadata": {"dbt_schema_version": "v20", "engine": "fusion-0.5"},
  "nodes": {
    "model.jaffle.orders": {
      "database": "analytics",
      "schema": "prod",
      "columns": {
        "order_id": {
          "data_type": "INTEGER",
          "nullable": false,
          "constraints": ["not_null", "unique"],
          "lineage_upstream": ["source.jaffle.stripe.orders"]
        }
      }
    }
  }
}

Nullability, constraints ja sarake-tason lineage ovat uusia. Käytännön hyöty: voit generoida column-lineage-katalogia (esim. DataHub) ilman erillistä SQL-parseria.

LSP-tuki VS Codelle: parempi kehityskokemus

Language Server Protocol on Microsoftin määrittelemä protokolla, jonka kautta editorit puhuvat kielikohtaisille "server"-prosesseille (esim. rust-analyzer, pyright, gopls). dbt-LSP-palvelin on osa Fusion-binääriä, ja se käynnistyy automaattisesti, kun asennat dbt Labs -laajennuksen VS Codeen (versio 0.6.0 tai uudempi).

Mitä LSP osaa syyskuun 2026 tilassa:

Go-to-definition. Cmd+klikkaa {{ ref('orders') }} ja hyppäät suoraan models/marts/orders.sql-tiedostoon. Sama toimii lähteille ja makroille.
Hover näyttää mallin kuvauksen (description-kenttä ymlistä), materialisoinnin ja viimeisimmän ajon aikaleiman.
Autotäydennys ref-, source- ja var-funktioille. Ei enää arvailua siitä, oliko malli nimeltään fct_orders vai fct_order.
Diagnostiikka reaaliaikaisesti. Kun tallennat SQL-tiedoston, LSP suorittaa staattisen analyysin ja korostaa tyyppimismatchit, tuntemattomat sarakkeet ja jinja-syntaksivirheet. Tämä on suurin ergonomiaparannus verrattuna v1.9:n dbt parse-silmukkaan.
Code actions. Pikaehdotukset esim. "lisää not_null-testi tälle sarakkeelle" tai "generoi yaml-schema tästä mallista".

Konfiguroi LSP-palvelin projektin .vscode/settings.json-tiedostoon:

{
  "dbt.enableLsp": true,
  "dbt.projectPath": "${workspaceFolder}",
  "dbt.profilesDir": "${env:HOME}/.dbt",
  "dbt.target": "dev",
  "dbt.strictSqlValidation": true,
  "dbt.staticTypeChecking": "warn"
}

strictSqlValidation ja staticTypeChecking ovat oletuksena pois päältä alpha-vaiheessa; kannattaa pakottaa "warn" tai "error", jotta ergonomiaetu tulee heti käyttöön.

Adapterit ja ELv2-lisensointi

Fusion-adapterit ovat trait-pohjaisia Rust-toteutuksia, jotka toimivat tietovaraston natiivilla protokollalla. Esim. Snowflake ODBC/JDBC ei ole enää välissä, vaan käytössä on suora Snowflake Query API. Tämä leikkaa jokaisen kyselyn round-trip-latenssia noin 30–50 ms:llä, mikä tuntuu isoissa DAG:eissa (yli 500 kyselyä per ajo).

Syyskuun 2026 GA-adapteri-tila:

Adapter	v1.9 (Python)	Fusion 0.5	dbt Core v2 alpha
Snowflake	GA	GA	GA
BigQuery	GA	GA	GA
Databricks	GA	GA	GA
Postgres	GA	GA	GA
Redshift	GA	GA	Beta
DuckDB	GA	Beta	Alpha
Trino	GA	Beta	Alpha
Athena	Community	Beta	Preview
ClickHouse	Community	Preview	Ei vielä

Käytännössä: jos data-alustasi pyörii Snowflaken, BigQueryn tai Databricksin päällä, voit siirtyä Fusioniin heti. Jos käytät DuckDB:tä paikallisiin kehitys- tai testiajoihin (esim. CI-pipelinessa), pysy toistaiseksi v1.9:ssä ja seuraa dbt-duckdb-repositorion Fusion-issueita.

ELv2-lisenssin käytännön merkitys: saat käyttää Fusionia sisäisiin ELT-pipelineihin, myydä konsultointia dbt:n ympärille ja sisällyttää sen SaaS-tuotteesi backendiin, kunhan tuotteesi ei ole dbt-as-a-service. Käytännössä tämä koskettaa vain hyvin harvaa tiimiä.

Microbatch-strategia inkrementaalisille malleille

Microbatch on inkrementaalinen materialisointistrategia, joka käsittelee mallia aikaikkuna kerrallaan (esim. yksi päivä, yksi tunti) sen sijaan, että käsittelisi koko datajoukon kerralla. Se julkaistiin betaksi v1.9:ssä ja on GA v1.9.3:sta lähtien; v2:ssa se säilyy oletusstrategiana isoille aikapohjaisille malleille. Toteutus näyttää tältä:

-- models/marts/fct_events_microbatch.sql
{{ config(
    materialized='incremental',
    incremental_strategy='microbatch',
    event_time='event_ts',
    batch_size='day',
    lookback=3,
    begin='2024-01-01'
) }}

select
    event_id,
    user_id,
    event_ts,
    event_type,
    properties
from {{ ref('stg_events') }}
where event_ts >= '{{ var("start_date") }}'
  and event_ts < '{{ var("end_date") }}'

batch_size='day' jakaa työn päiväikkunoihin. lookback=3 ajaa uudelleen viimeiset 3 aikaikkunaa jokaisella ajolla, mikä on käytännöllinen ratkaisu, kun myöhäistulevat tapahtumat (late-arriving data) ovat mahdollisia. begin asettaa aikaleiman, josta ensimmäinen backfill alkaa.

Miksi tämä on iso juttu? Aiemmin backfill oli tuska: kirjoitit dbt run --full-refresh --select fct_events, dbt yritti kirjoittaa koko 2 vuoden ajanjakson yhtenä transaktiona, ja tietovarasto joko ajautui out-of-memoryyn tai kesti 6 tuntia. Microbatchissa ajat dbt run --event-time-start '2025-01-01' --event-time-end '2025-04-01' --select fct_events ja dbt jakaa sen 90 päiväikkunaan, jotka voidaan ajaa myös rinnakkain adapterin salliessa.

Testit dbt:ssä 2026: unit-testit ja pipeline-tarkistukset

Data-tiimeissä testeistä tingitään aivan liian usein, ja se kostautuu backfilleissä. Oma suositukseni analytiikkainsinöörinä, joka on tehnyt useamman dbt-migraation: testejä ei laimenneta v2:een migraation aikana. Päinvastoin, otetaan uudet unit_tests käyttöön samalla vaivalla.

Unit-testit ilmestyivät v1.8:aan (huhtikuu 2024) ja niiden syntax on stabiili:

# models/marts/_orders__unit_tests.yml
unit_tests:
  - name: test_orders_removes_test_users
    model: fct_orders
    given:
      - input: ref('stg_orders')
        rows:
          - {order_id: 1, user_id: 100, status: 'paid'}
          - {order_id: 2, user_id: 999, status: 'paid'}  # 999 on testikäyttäjä
      - input: ref('stg_test_users')
        rows:
          - {user_id: 999}
    expect:
      rows:
        - {order_id: 1, user_id: 100, status: 'paid'}

Fusionin unit-testit ajetaan muistissa (in-memory). Testit eivät osu tietovarastoon, mikä tekee niistä 100–500× nopeampia kuin perinteiset dbt-testit. Käytännössä 200 unit-testin sarja ajautuu 4–8 sekunnissa. CI-pipelinessa voit ajaa unit-testit jokaisella PR:llä, ja data-testit (perinteiset not_null, unique, relationships) vain merge-vaiheessa.

Tuotannon data-laatua kannattaa täydentää Great Expectations- tai Elementary-integraatiolla. Great Expectations osaa validoida taulun jakaumat, uniikkiarvot ja ristiviittaukset. Se sopii ylimääräiseksi tarkistuskerrokseksi dbt-testien päälle. Suosittelen lukemaan aiemman tarkemman oppaan scikit-learn Pipeline -työkalusta, jos rakennat myös ML-pipelineja saman dbt-projektin päälle. Sama "pipeline-testi ei ole neuvoteltavissa" -periaate pätee kummallakin puolella.

Kolme testauksen periaatetta, joista en tingi (törmäsin näihin viime projektissa niin monta kertaa, että päätin kirjata ne muistiin):

Jokaisella staging-mallilla on ainakin not_null primaariavaimelle ja unique. Näiden puuttuminen on suurin syy, miksi backfill kaatuu tuntien pyöriteltyään.
Freshness-tarkistus jokaiselle lähteelle. freshness: {warn_after: {count: 12, period: hour}, error_after: {count: 24, period: hour}}. Jos data ei tule, sinun täytyy tietää siitä ennen kuin analyytikot huomaavat.
Unit-testit isoille bisnesloogisille malleille. Ei kaikille, vaan malleille, joissa on if/then/else-logiikkaa tai monta liitosta.

Migraatio dbt Core v1.9:stä v2:een askel askeleelta

Suositeltu migraatiopolku on kolmivaiheinen. En suosittele hyppäämistä suoraan v1.7:stä v2:een. v1.9 on hyvä välivaihe, koska microbatch, unit-testit ja Fusion-yhteensopivat manifest-kentät ovat siinä jo mukana.

Vaihe 1: nosta v1.9:ään

# pyproject.toml
[project]
dependencies = [
    "dbt-core==1.9.3",
    "dbt-snowflake==1.9.1",  # tai muu adapter
]

# ajetaan
uv sync
dbt --version  # varmista 1.9.3
dbt parse
dbt build --select state:modified+ --defer --state ./target-prod

Vaihe 2: asenna Fusion rinnakkaisena

# asenna Fusion CLI (Homebrew tai binary release)
brew install dbt-labs/tap/dbt-fusion
dbt-fusion --version  # 0.5.x

# tarkista projekti Fusionilla ilman ajoa
dbt-fusion parse --project-dir .
dbt-fusion compile --project-dir . --target dev

Fusion parsii samat dbt_project.yml-, models/- ja tests/-hakemistot, mutta huomaat välittömästi eron nopeudessa. Jos parsi kaatuu, syy on lähes aina jokin näistä: Jinja-makro käyttää poistettua funktiota (invocation_args_dict vanhalla nimellä), packages.yml viittaa hub-paketteihin, joita ei ole päivitetty Fusion-yhteensopiviksi, tai käytät dbt_utils.pivot()-makron vanhaa allekirjoitusta.

Vaihe 3: vaihda dbt Core v2 alphaan

# erillinen virtuaaliympäristö testejä varten
uv venv .venv-v2
source .venv-v2/bin/activate
uv pip install "dbt-core==2.0.0a3" "dbt-snowflake==2.0.0a3"

dbt --version
# dbt-core: 2.0.0a3 (engine: fusion 0.5.2)
dbt parse
dbt build --select state:modified+

dbt Fusion vs SQLMesh vs SDF: vertailu

Rustissa toteutettuja SQL-transformaatiokehyksiä on nyt useampi, ja rehellisyyden nimissä on hyvä katsoa vaihtoehdot. Vertailu syyskuun 2026 tilassa:

Ominaisuus	dbt Fusion 0.5 / v2	SQLMesh 0.55	SDF 0.20
Runtime-kieli	Rust	Python + Rust-parseri	Rust
Semanttinen parsi	Kyllä (Fusion 0.5+)	Kyllä (SQLGlot)	Kyllä
Yksikkötestit muistissa	Kyllä	Kyllä	Kyllä
Migraatio dbt:stä	Sama syntaksi	dbt-yhteensopivuustila	Konvertointi tarvitaan
Aikapohjaiset inkrementit	Microbatch	Time-based partitions	Time bounds
Semanttinen versiointi mallille	Ei	Kyllä (breaking change detection)	Ei
Adapter-tarjonta	Laaja (5+ GA)	Keskitaso (3 GA)	Rajattu (Snowflake, BigQuery)
Lisenssi	Apache 2.0 / ELv2	Apache 2.0	ELv2
Yhteisö-adaptereita	Kyllä	Kyllä	Vähän

Käytännön suositus:

Jos tiimisi on jo dbt:ssä ja projektissa on 200+ mallia, pysy dbt:ssä ja siirry Fusioniin heti kun adapterisi on GA. Migraatiokustannus on lähellä nollaa.
Jos aloitat vihreältä pohjalta ja arvostat SQLGlot-tason parsimista ja breaking change -tunnistusta, SQLMesh on vahva kandidaatti.
SDF on Snowflake- ja BigQuery-keskeinen. Jos toimit muualla, valinta rajoittuu käytännössä kahteen edelliseen.

Vaikka valinta olisi mikä tahansa, muista testaus. Se on ainoa asia, joka pitää yön yli ajautuvat pipelinet elossa ja päivystäjät nukkumassa.

Käytännön CI-pipeline dbt Fusionille (GitHub Actions)

Tässä on täydellinen esimerkki CI-workflowsta, jota käytän Fusion-projekteissa (kopioi ja muokkaa oman ympäristösi mukaan):

name: dbt CI

on:
  pull_request:
    paths: ['models/**', 'tests/**', 'macros/**', 'dbt_project.yml']

jobs:
  parse-and-test:
    runs-on: ubuntu-latest
    env:
      DBT_PROFILES_DIR: ./
      SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
      SNOWFLAKE_USER: ${{ secrets.SNOWFLAKE_USER }}
      SNOWFLAKE_KEY: ${{ secrets.SNOWFLAKE_KEY }}
    steps:
      - uses: actions/checkout@v4
      - name: Install dbt Fusion
        run: |
          curl -fsSL https://get.dbt.com/fusion | bash -s -- --version 0.5.2
          dbt-fusion --version
      - name: Fetch production manifest
        run: |
          aws s3 cp s3://dbt-manifests/prod/manifest.json ./target-prod/manifest.json
      - name: Parse and static check
        run: dbt-fusion parse --strict
      - name: Unit tests (in-memory)
        run: dbt-fusion test --select unit_test --defer --state ./target-prod
      - name: Modified models only
        run: dbt-fusion build --select state:modified+ --defer --state ./target-prod

Kaksi asiaa, jotka tekevät tästä nopean:

--select state:modified+ rakentaa vain muuttuneet mallit ja niiden jälkeläiset, ei koko DAG:ia.
--defer --state ./target-prod käyttää tuotannon manifest.jsonia, joten muuttumattomat riippuvuudet luetaan tuotannon skeemasta eikä niitä rakenneta uudelleen.

Yksi lisähuomio testeistä: älä koskaan salli PR:n mennä läpi, jos dbt-fusion test palauttaa nollan riviä. Se on merkki siitä, että testejä ei ole määritelty, ei siitä, että kaikki menee hyvin.

Usein kysyttyä

Onko dbt Fusion ilmainen käyttää?

Kyllä. dbt Fusion on avoin lähdekoodi Apache 2.0 -lisenssillä ja käytettävissä ilman dbt Cloud -tilausta. Se on ladattavissa GitHub-julkaisusivulta ja asennettavissa Homebrewilla tai binaarisena.

Miten dbt Fusion eroaa dbt Coresta?

dbt Core on Python-pohjainen kääntäjä ja runtime; dbt Fusion on Rust-pohjainen suorituskoneisto, joka jäsentää ja kääntää projektin 20–30× nopeammin ja tarjoaa staattisen SQL-tyyppitarkistuksen. dbt Core v2 käyttää Fusion-runtimea sisäisesti.

Voinko käyttää dbt Fusionia dbt Cloudin kanssa?

Kyllä. dbt Cloud käyttää Fusion-runtimea kaikissa uusissa projekteissa joulukuusta 2025 alkaen, ja olemassa olevat projektit voi vaihtaa asetuksista. Fusion-CLI toimii myös paikallisesti dbt Cloudin ulkopuolella.

Mitä eroa on manifest v12:lla ja v20:lla?

manifest v20 sisältää sarake-tason nullability-tiedon, constraints-metadatan ja sarakkeen tason lineage-linkit. v12 sisälsi vain karkean mallitason lineage-graafin. v20 on tarpeen esim. DataHubin column-lineage-integraatiolle ilman erillistä SQL-parseria.

Onko dbt-unit-testejä pakko käyttää?

Ei pakko, mutta suositellaan vahvasti monimutkaisille bisneslogiikkamalleille. Unit-testit ajetaan muistissa 100–500× nopeammin kuin perinteiset data-testit, joten ne sopivat CI-vaiheeseen. Perinteiset dbt-testit (not_null, unique, relationships) täydentävät niitä ja ajetaan tuotannossa oikeaa dataa vasten.

Milloin dbt Core v2 tulee GA:ksi?

dbt Labs on ilmoittanut GA-julkaisusta joulukuulle 2026. Syyskuussa 2026 versio 2.0.0a3 on alpha-vaiheessa, ja sitä suositellaan testattavaksi rinnakkaisympäristössä ennen tuotantokäyttöä.