Bazel, सोर्स कोड से सॉफ़्टवेयर बनाता है. सोर्स कोड को डायरेक्ट्री ट्री में व्यवस्थित किया जाता है, जिन्हें रिपॉज़िटरी कहा जाता है. वर्कस्पेस, रिपॉज़िटरी के तय किए गए सेट से बना होता है. रिपॉज़िटरी में मौजूद सोर्स फ़ाइलों को पैकेज के नेस्ट किए गए क्रम में व्यवस्थित किया जाता है. यहां हर पैकेज एक डायरेक्ट्री होती है, जिसमें मिलती-जुलती सोर्स फ़ाइलों का एक सेट और एक BUILD फ़ाइल होती है. BUILD फ़ाइल से यह तय होता है कि सोर्स से कौनसे सॉफ़्टवेयर आउटपुट बनाए जा सकते हैं.
डेटा स्टोर करने की जगह
Bazel बिल्ड में इस्तेमाल की गई सोर्स फ़ाइलों को डेटा स्टोर करने की जगह में व्यवस्थित किया जाता है. इसे अक्सर डेटा स्टोर करने की जगह कहा जाता है. कोई रिपॉज़िटरी, एक डायरेक्ट्री ट्री होती है, जिसकी रूट में एक बाउंड्री मार्कर फ़ाइल होती है. यह बाउंड्री मार्कर फ़ाइल MODULE.bazel, REPO.bazel या लेगसी कॉन्टेक्स्ट में WORKSPACE या WORKSPACE.bazel हो सकती है.
जिस repo में मौजूदा Bazel कमांड चलाया जा रहा है उसे main repo कहा जाता है. अन्य (बाहरी) रिपॉज़िटरी, रिपॉज़िटरी के नियमों के हिसाब से तय की जाती हैं. ज़्यादा जानकारी के लिए, बाहरी डिपेंडेंसी की खास जानकारी देखें.
Workspace
वर्कस्पेस, एक ही मुख्य रिपॉज़िटरी से चलाए जाने वाले सभी Bazel निर्देशों के लिए शेयर किया जाने वाला एनवायरमेंट होता है. इसमें मुख्य रिपॉज़िटरी और तय किए गए सभी बाहरी रिपॉज़िटरी का सेट शामिल होता है.
ध्यान दें कि "रिपॉज़िटरी" और "वर्कस्पेस" के कॉन्सेप्ट को ऐतिहासिक तौर पर एक ही माना जाता रहा है. "वर्कस्पेस" शब्द का इस्तेमाल अक्सर मुख्य रिपॉज़िटरी के लिए किया जाता है. कभी-कभी, इसका इस्तेमाल "रिपॉज़िटरी" के लिए भी किया जाता है.
पैकेज
रिपॉज़िटरी में कोड संगठन की मुख्य इकाई पैकेज होती है. पैकेज, मिलती-जुलती फ़ाइलों का कलेक्शन होता है. साथ ही, इसमें यह जानकारी भी होती है कि आउटपुट आर्टफ़ैक्ट बनाने के लिए, इन फ़ाइलों का इस्तेमाल कैसे किया जा सकता है.
पैकेज को ऐसी डायरेक्ट्री के तौर पर परिभाषित किया जाता है जिसमें BUILD या BUILD.bazel नाम की BUILD फ़ाइल मौजूद हो. किसी पैकेज में, उसकी डायरेक्ट्री में मौजूद सभी फ़ाइलें और उसके नीचे मौजूद सभी सबडायरेक्ट्री शामिल होती हैं. हालांकि, उन सबडायरेक्ट्री को शामिल नहीं किया जाता जिनमें BUILD फ़ाइल मौजूद होती है. इस परिभाषा के मुताबिक, कोई भी फ़ाइल या डायरेक्ट्री दो अलग-अलग पैकेज का हिस्सा नहीं हो सकती.
उदाहरण के लिए, यहां दिए गए डायरेक्ट्री ट्री में दो पैकेज, my/app और सब-पैकेज my/app/tests हैं. ध्यान दें कि my/app/data कोई पैकेज नहीं है, बल्कि यह my/app पैकेज की डायरेक्ट्री है.
src/my/app/BUILD
src/my/app/app.cc
src/my/app/data/input.txt
src/my/app/tests/BUILD
src/my/app/tests/test.cc
टारगेट
पैकेज, टारगेट का कंटेनर होता है. इन टारगेट के बारे में पैकेज की BUILD फ़ाइल में बताया जाता है. ज़्यादातर टारगेट, दो मुख्य तरह के होते हैं: फ़ाइलें और नियम.
फ़ाइलों को दो तरह में बांटा गया है. आम तौर पर, सोर्स फ़ाइलें लोगों की मेहनत से लिखी जाती हैं और उन्हें रिपॉज़िटरी में चेक इन किया जाता है. जनरेट की गई फ़ाइलों को कभी-कभी डिराइव्ड फ़ाइलें या आउटपुट फ़ाइलें भी कहा जाता है. इन फ़ाइलों में चेक इन नहीं किया जाता, लेकिन इन्हें सोर्स फ़ाइलों से जनरेट किया जाता है.
दूसरे तरह के टारगेट को नियम के साथ तय किया गया है. हर नियम के इंस्टेंस में, इनपुट और आउटपुट फ़ाइलों के सेट के बीच का संबंध बताया जाता है. किसी नियम के इनपुट, सोर्स फ़ाइलें हो सकती हैं. हालांकि, ये अन्य नियमों के आउटपुट भी हो सकते हैं.
ज़्यादातर मामलों में, चाहे नियम का इनपुट कोई सोर्स फ़ाइल है या जनरेट की गई फ़ाइल, ज़्यादातर मामलों में अभौतिक है; सिर्फ़ उस फ़ाइल के कॉन्टेंट का ही महत्व है. इस वजह से, किसी नियम के हिसाब से जनरेट की गई फ़ाइल को, किसी जटिल सोर्स फ़ाइल से आसानी से बदला जा सकता है. ऐसा तब होता है, जब किसी ज़्यादा व्यवस्थित फ़ाइल को मैन्युअल तरीके से मैनेज करना बहुत मुश्किल हो जाता है और कोई व्यक्ति उसे जनरेट करने के लिए कोई प्रोग्राम लिखता है. उस फ़ाइल के उपभोक्ताओं के लिए किसी बदलाव की आवश्यकता नहीं है. इसके उलट, जनरेट की गई फ़ाइल को सिर्फ़ स्थानीय बदलावों वाली सोर्स फ़ाइल से बदला जा सकता है.
किसी नियम के इनपुट में अन्य नियम भी शामिल हो सकते हैं. इस तरह के संबंधों का सटीक मतलब अक्सर काफ़ी जटिल होता है और यह भाषा या नियम पर निर्भर करता है. हालांकि, यह आसानी से समझा जा सकता है: किसी C++ लाइब्रेरी नियम A में, इनपुट के लिए कोई दूसरा C++ लाइब्रेरी नियम B हो सकता है. इस डिपेंडेंसी का असर यह होता है कि B की हेडर फ़ाइलें, कंपाइलेशन के दौरान A को उपलब्ध हो जाती हैं. लिंक करने के दौरान B के सिंबल A को उपलब्ध हो जाते हैं. साथ ही, B के रनटाइम डेटा को एक्ज़ीक्यूशन के दौरान A के लिए उपलब्ध कराया जाता है.
सभी नियमों के लिए यह एक ज़रूरी शर्त है कि किसी नियम से जनरेट की गई फ़ाइलें हमेशा उसी पैकेज से जुड़ी होती हैं जिसमें नियम मौजूद होता है. किसी दूसरे पैकेज में फ़ाइलें जनरेट नहीं की जा सकतीं. हालांकि, यह आम बात है कि किसी नियम के इनपुट किसी दूसरे पैकेज से आते हैं.
पैकेज ग्रुप, पैकेज के ऐसे सेट होते हैं जिनका मकसद कुछ नियमों के ऐक्सेस को सीमित करना होता है. पैकेज ग्रुप, package_group फ़ंक्शन से तय किए जाते हैं. इनमें तीन प्रॉपर्टी होती हैं: इनमें शामिल पैकेज की सूची, उनका नाम, और इनमें शामिल अन्य पैकेज ग्रुप. इनका रेफ़रंस देने के लिए, सिर्फ़ नियमों के visibility एट्रिब्यूट या package फ़ंक्शन के default_visibility एट्रिब्यूट का इस्तेमाल किया जा सकता है. ये फ़ाइलें जनरेट या इस्तेमाल नहीं करते. ज़्यादा जानकारी के लिए, package_group के दस्तावेज़ देखें.