Packaging και deploy των Boomi processes ανά περιβάλλον

Ο συγχρονισμός παραγγελιών ανάμεσα σε e-shop και ERP δουλεύει στο test. Τώρα πρέπει να φτάσει στην παραγωγή, τον επόμενο μήνα θα ακολουθήσει μια αλλαγή, και τον μεθεπόμενο άλλη μία. Σε αυτό το άρθρο εξηγούμε πώς κάθε τέτοιο βήμα γίνεται release με έκδοση, επαναλήψιμο και με δρόμο επιστροφής, και πώς γίνεται στο Boomi, πρώτα χειροκίνητα και μετά από ένα CI pipeline.

Το πρόβλημα με το «κάνε deploy το τελευταίο»

Χωρίς πειθαρχία στα releases, τα deploys ξεφεύγουν:

• Κανείς δεν ξέρει τι τρέχει στην παραγωγή. Το «τελευταία έκδοση» σημαίνει άλλο πράγμα για τον καθένα.
• Μπαίνουν αλλαγές που δεν δοκιμάστηκαν. Κάποιος αποθήκευσε μια μισοτελειωμένη αλλαγή σε ένα κοινό map, και αυτή ταξιδεύει με το επόμενο deploy.
• Το rollback είναι μαντεία. Όταν η νέα έκδοση φτιάχνει διπλά τιμολόγια, ποια ήταν η καλή;
• Τα releases δεν έχουν ιστορία. Έξι μήνες μετά, κανείς δεν θυμάται γιατί άλλαξε το mapping του ΦΠΑ.

Το pattern: αμετάβλητα packages με εκδόσεις

Το pattern της παράδοσης λογισμικού δουλεύει και στα integrations:

1. Παγώνετε το integration και ό,τι χρειάζεται σε ένα package με αριθμό έκδοσης και σημειώσεις.
2. Προωθείτε το ίδιο package από περιβάλλον σε περιβάλλον: test, μετά παραγωγή. Ποτέ νέο build για την παραγωγή.
3. Αλλάζετε μόνο ρυθμίσεις ανάμεσα στα περιβάλλοντα, ποτέ το package.
4. Κάνετε rollback ξανακάνοντας deploy το προηγούμενο package.

Build ──► Package v1.4.0 ──► Test ──(έγκριση)──► Παραγωγή
                                                  ▲
                      Package v1.3.2 ─── rollback ┘

Βήμα 1: Δημιουργήστε packaged component

Στο Boomi, ένα packaged component είναι ένα παγωμένο στιγμιότυπο με έκδοση ενός process (ή άλλου component που γίνεται deploy, όπως ένα API Service) μαζί με όλα τα components που αυτό χρησιμοποιεί: connections, operations, maps, profiles.

1. Ανοίξτε το process, για παράδειγμα Orders | E-shop to ERP, και βεβαιωθείτε ότι όλες οι αλλαγές είναι αποθηκευμένες.
2. Επιλέξτε Create Packaged Component (από το process ή από την περιοχή Deploy).
3. Επιβεβαιώστε ότι περιλαμβάνονται το component και τα εξαρτώμενα components του.
4. Δώστε έκδοση, για παράδειγμα 1.4.0, και σημειώσεις. Το Boomi μπορεί να προτείνει έκδοση, αλλά μια σύμβαση που επιλέγετε εσείς επικοινωνείται ευκολότερα.
5. Δημιουργήστε το package. Δεν αλλάζει πια· μια επόμενη διόρθωση γίνεται έκδοση 1.4.1.

Μια χρήσιμη σύμβαση: major έκδοση για αλλαγές στο συμβόλαιο με άλλα συστήματα, minor για νέες λειτουργίες, patch για διορθώσεις. Ό,τι κι αν διαλέξετε, εφαρμόστε το με συνέπεια.

Release notes που βοηθούν στις 2 τα ξημερώματα

Οι σημειώσεις είναι η φθηνότερη τεκμηρίωση που θα γράψετε ποτέ. Κρατήστε τις σύντομες και συγκεκριμένες:

1.4.0 - 2026-10-20 - Μαρία Π.
- Παραγγελίες με τρόπο αποστολής "παραλαβή από κατάστημα" πηγαίνουν στην αποθήκη W02 του ERP (ticket INT-231)
- Ο ΑΦΜ πελάτη καθαρίζεται από κενά πριν την αναζήτηση· διορθώνει διπλούς πελάτες όπως ο C-1042
- Δεν χρειάζονται αλλαγές ρυθμίσεων

Η τελευταία γραμμή μετράει: πείτε αν πρέπει να ενημερωθούν environment extensions πριν το deploy.

Βήμα 2: Deploy στο test

1. Πηγαίνετε στο Deploy → Packaged Components (οι ακριβείς ετικέτες διαφέρουν λίγο ανά έκδοση), βρείτε το package και επιλέξτε deploy.
2. Επιλέξτε το περιβάλλον test και προσθέστε σημειώσεις deploy αν βοηθούν.
3. Ελέγξτε ότι τα environment extensions για κάθε νέο connection ή property έχουν οριστεί πριν την πρώτη εκτέλεση.
4. Τρέξτε τα tests σας. Δείτε το testing των Boomi processes για το τι να καλύψετε.

Βήμα 3: Προώθηση στην παραγωγή

Όταν περάσει το test και εγκριθεί η αλλαγή, κάντε deploy την ίδια έκδοση package στο περιβάλλον παραγωγής. Μη δημιουργήσετε νέο package από την τρέχουσα κατάσταση του process· μπορεί να περιέχει ήδη μισοτελειωμένη δουλειά κάποιου άλλου.

Χρησιμοποιήστε την πρόσβαση βάσει ρόλων του Boomi ώστε μόνο release managers ή διαχειριστές να κάνουν deploy στην παραγωγή, και καταγράψτε την έγκριση (αριθμό ticket, εγκρίνοντα) στις σημειώσεις του deploy.

Βήμα 4: Rollback με deploy της προηγούμενης έκδοσης

Αν η έκδοση 1.4.0 δεν συμπεριφέρεται σωστά στην παραγωγή:

1. Ανοίξτε το ιστορικό deploys του process στο περιβάλλον παραγωγής.
2. Βρείτε το προηγούμενο package, 1.3.2, και κάντε το ξανά deploy στην παραγωγή.
3. Επιβεβαιώστε ότι το runtime δείχνει πλέον την 1.3.2 ως deployed έκδοση, και ελέγξτε τις επόμενες εκτελέσεις.

Το rollback επαναφέρει τη λογική, όχι τα δεδομένα. Αν η 1.4.0 έχει ήδη δημιουργήσει λάθος εγγραφές στο ERP, πρέπει να τις διορθώσετε. Είναι ένας λόγος να κρατάτε τα releases μικρά.

Επίσης, τα environment extensions δεν είναι μέρος του package. Αν η 1.4.0 χρειάστηκε νέα τιμή extension, το rollback δεν την αφαιρεί, κάτι συνήθως αβλαβές, αλλά καλό να το ξέρετε.

Βήμα 5: Αυτοματισμός με το Boomi Platform API

Όταν τα χειροκίνητα releases δουλεύουν, ένα CI pipeline (GitHub Actions, Azure DevOps, Jenkins) μπορεί να κάνει τα ίδια βήματα μέσω του Boomi Platform API (παλαιότερα AtomSphere API). Τα σχετικά objects περιλαμβάνουν το PackagedComponent (δημιουργία package) και το DeployedPackage (deploy ενός package σε περιβάλλον και αναζήτηση του τι είναι deployed). Ελέγξτε το τρέχον API reference για τα ακριβή ονόματα πεδίων και την ταυτοποίηση· τα παραδείγματα δείχνουν τη μορφή των κλήσεων.

Δημιουργήστε API token για έναν αποκλειστικό service user, αποθηκεύστε το ως secret του pipeline και ταυτοποιηθείτε με αυτό:

BASE="https://api.boomi.com/api/rest/v1/${BOOMI_ACCOUNT_ID}"
AUTH="BOOMI_TOKEN.${BOOMI_USER}:${BOOMI_API_TOKEN}"

# 1. Δημιουργία packaged component για το process
curl -s -u "$AUTH" -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "$BASE/PackagedComponent" \
  -d '{ "componentId": "'"$PROCESS_ID"'", "packageVersion": "1.4.0", "notes": "INT-231 store pickup mapping" }'

# 2. Deploy του package (packageId από το βήμα 1) στο περιβάλλον test
curl -s -u "$AUTH" -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "$BASE/DeployedPackage" \
  -d '{ "environmentId": "'"$TEST_ENV_ID"'", "packageId": "'"$PACKAGE_ID"'", "notes": "CI build 512" }'

Ένα τυπικό pipeline:

# Σκαρίφημα workflow στο GitHub Actions
jobs:
  package-and-deploy-test:
    steps:
      - run: ./scripts/boomi-create-package.sh "$VERSION"
      - run: ./scripts/boomi-deploy.sh "$PACKAGE_ID" "$TEST_ENV_ID"
      - run: ./scripts/run-regression-tests.sh
  deploy-production:
    needs: package-and-deploy-test
    environment: production   # απαιτεί έγκριση στο GitHub
    steps:
      - run: ./scripts/boomi-deploy.sh "$PACKAGE_ID" "$PROD_ENV_ID"

Το job της παραγωγής κάνει deploy το package ID που δημιουργήθηκε νωρίτερα, ποτέ νέο. Το βήμα έγκρισης του pipeline γίνεται το αρχείο change control. Συνδυάστε το με αυτοματοποιημένα tests όπως περιγράφουμε στο regression testing για Boomi integrations.

Πριν βγείτε στην παραγωγή

• Συμφωνήστε σύμβαση εκδόσεων και πρότυπο για release notes.
• Περιορίστε το deploy στην παραγωγή σε μια μικρή ομάδα ή στον service user του pipeline.
• Ελέγξτε τα extensions στο περιβάλλον-στόχο πριν από κάθε release που προσθέτει connections ή properties.
• Κάντε πρόβα rollback στο test, για να ξέρετε πόσο χρόνο παίρνει.
• Προστατέψτε το API token: αποκλειστικός χρήστης, αποθήκευση ως secret του pipeline, rotation όπως κάθε διαπιστευτήριο.
• Παρακολουθήστε τις πρώτες εκτελέσεις μετά από κάθε deploy· δείτε το Monitoring των Boomi integrations.

Συμπέρασμα

Αντιμετωπίστε κάθε αλλαγή ως παγωμένο package με έκδοση, που προωθείται αναλλοίωτο από το test στην παραγωγή, με σημειώσεις που το εξηγούν και την προηγούμενη έκδοση έτοιμη για deploy. Τα packaged components του Boomi σάς τα δίνουν έτοιμα, και το Platform API επιτρέπει στο εργαλείο CI να τα οδηγεί. Για τη συνολική εικόνα, δείτε τον οδηγό μας DevOps για integrations.