Co to jest narzędzie do kompilacji?

Od 4 lat programuję w Eclipse (dla Javy) i Visual Studio Express (dla C #). Wymienione IDE zawsze wydawały się zapewniać wszelkie ułatwienia, o jakie prosi programista (oczywiście związane z programowaniem).

Ostatnio słyszałem o czymś, co nazywa się „narzędziami do budowania”. Słyszałem, że są używane prawie we wszystkich rodzajach rozwoju w świecie rzeczywistym. Czym one dokładnie są? Jakie problemy mają rozwiązać? Dlaczego nigdy ich nie potrzebowałem przez ostatnie cztery lata? Czy są to jakby pozbawione wiersza poleceń IDE?

Co to są narzędzia do budowania?

Narzędzia do budowania to programy, które automatyzują tworzenie aplikacji wykonywalnych z kodu źródłowego (np. .Apk dla aplikacji na Androida). Budowanie obejmuje kompilowanie, łączenie i pakowanie kodu w użyteczną lub wykonywalną formę.

Zasadniczo automatyzacja kompilacji polega na pisaniu skryptów lub automatyzowaniu szerokiej gamy zadań, które programiści wykonują w codziennych czynnościach, takich jak:

1. Pobieranie zależności.
2. Kompilowanie kodu źródłowego do kodu binarnego.
3. Pakowanie tego kodu binarnego.
4. Przeprowadzanie testów.
5. Wdrożenie do systemów produkcyjnych.

Dlaczego używamy narzędzi do kompilacji lub automatyzacji kompilacji?

W małych projektach programiści często ręcznie wywołują proces kompilacji. Jest to niepraktyczne w przypadku większych projektów, w których bardzo trudno jest śledzić, co należy zbudować, w jakiej kolejności i jakie zależności występują w procesie budowania. Korzystanie z narzędzia do automatyzacji zapewnia większą spójność procesu kompilacji.

Dostępne różne narzędzia do budowania (tylko kilka nazw):

1. Dla java - Ant, Maven, Gradle.
2. Dla .NET Framework - NAnt
3. c # - MsBuild.

Więcej informacji można znaleźć pod następującymi linkami:

1. Buduj automatyzację

2. Lista oprogramowania do automatyzacji kompilacji

Dzięki.

Narzędzia do budowania to narzędzia do zarządzania i organizowania kompilacji i są bardzo ważne w środowiskach, w których występuje wiele projektów, zwłaszcza jeśli są one ze sobą połączone. Służą do upewnienia się, że tam, gdzie różne osoby pracują nad różnymi projektami, niczego nie zepsują. I żeby mieć pewność, że kiedy wprowadzisz zmiany, one też niczego nie zepsują.

Powodem, dla którego wcześniej o nich nie słyszałeś, jest to, że wcześniej nie pracowałeś w środowisku komercyjnym. Jest wiele rzeczy, z którymi prawdopodobnie nie spotkałeś się w środowisku komercyjnym, zwłaszcza jeśli pracujesz w software house'ach.

Jak powiedzieli inni, korzystałeś z nich, jednak nie musiałeś ich rozważać, ponieważ prawdopodobnie pracowałeś w inny sposób niż zwykły komercyjny sposób pracy.

Narzędzia do budowania są zwykle uruchamiane z wiersza poleceń, wewnątrz IDE lub całkowicie od niego.

Chodzi o to, aby oddzielić pracę związaną z kompilacją i pakowaniem kodu od tworzenia, debugowania itp.

Narzędzie do budowania można uruchomić za pomocą polecenia lub wewnątrz IDE, oba wyzwalane przez Ciebie. Mogą być również używane przez narzędzia do ciągłej integracji po sprawdzeniu kodu z repozytorium na czystą maszynę do kompilacji.

make było wczesnym narzędziem poleceń używanym w środowiskach * nix do budowania C / C ++.

Jako programista Java najpopularniejszymi narzędziami do budowania są Ant i Maven. Oba mogą działać w IDE, takich jak IntelliJ, Eclipse lub NetBeans. Mogą być również używane przez narzędzia do ciągłej integracji, takie jak Cruise Control lub Hudson.

Narzędzia do budowania służą przeważnie do przekształcania kodu źródłowego w pliki binarne - organizują kod źródłowy, ustawiają flagi kompilacji, zarządzają zależnościami ... niektóre z nich integrują się również z uruchomieniem testów jednostkowych, przeprowadzaniem analiz statycznych, generowaniem dokumentacji.

Eclipse lub Visual Studio to również systemy kompilacji (ale bardziej IDE), a dla Visual Studio jest to podstawowy program msbuild do analizowania plików projektów Visual Studio pod maską.

Pochodzenie wszystkich systemów kompilacji wydaje się być podobne do słynnej marki.

Istnieją systemy kompilacji dla różnych języków:

1. C ++: make, cmake, premake
2. Java: ant + ivy, maven, gradle
3. C #: msbuild

Zwykle buduj systemy przy użyciu języka specyficznego dla domeny (make, cmake) lub xml (ant, maven, msbuild), aby określić build. Obecny trend polega na używaniu prawdziwego języka skryptowego do pisania skryptu kompilacji, takiego jak lua dla premake i groovy dla gradle, zaletą korzystania ze skryptów jest to, że jest on znacznie bardziej elastyczny, a także pozwala wymyślić zestaw standardowych API (jako kompilacja DSL).

Proces kompilacji to proces kompilowania kodu źródłowego pod kątem wszelkich błędów przy użyciu niektórych narzędzi do kompilacji i tworzenia kompilacji (które są wykonywalnymi wersjami projektu). My (głównie programiści) dokonujemy pewnych modyfikacji w kodzie źródłowym i rejestrujemy ten kod, aby mógł nastąpić proces kompilacji. Po procesie budowania daje to dwa wyniki: 1. Albo buduj PASSES i otrzymujesz wykonywalną wersję swojego projektu (kompilacja jest gotowa). 2. To się nie powiedzie i otrzymujesz pewne błędy, a kompilacja nie zostanie utworzona.

Istnieją różne typy procesu budowania, takie jak: 1. Nightly Build 2. Brated Build 3. Ciągła integracja itd.

Narzędzia kompilacji pomagają i automatyzują proces tworzenia kompilacji.

* Tak więc w wersji Short Build jest wersja oprogramowania w formacie przedpremierowym, używana przez programistów lub zespół programistów w celu uzyskania pewności co do końcowego wyniku ich Produktu poprzez ciągłe monitorowanie ich Produktu i rozwiązywanie wszelkich problemów na wczesnym etapie procesu rozwoju. *

Są to różne typy procesów, za pomocą których można tworzyć kompilacje.

1. Budowa ciągłej integracji:W tym przypadku głównie programiści rejestrują swój kod i zaraz po ich zarejestrowaniu rozpoczyna się kompilacja w celu zbudowania ostatnich zmian, więc powinniśmy wiedzieć, czy zmiany wprowadzone przez programistę zadziałały, czy nie, zaraz po zakończeniu rejestracji. Jest to preferowane w przypadku mniejszych projektów lub składników projektów. W przypadku, gdy wiele zespołów jest powiązanych z projektem lub występuje duża liczba nie. deweloperów pracujących nad tym samym projektem, scenariusz ten staje się trudny do zrealizowania, tak jakby było „n” nie. rejestracji, a kompilacja kończy się niepowodzeniem w pewnych momentach, bardzo trudno jest prześledzić, czy wszystkie awarie wystąpiły z powodu jednego problemu, czy z wieloma problemami, więc jeśli starsze problemy nie zostaną odpowiednio rozwiązane, bardzo trudno będzie wyśledzić później wady, które wystąpiły po tej zmianie.

2. Bramowane konstrukcje do odprawy: W tego rodzaju kontroli kompilacja jest inicjowana zaraz po zakończeniu rejestracji, zachowując zmiany w zestawach półek. W takim przypadku, jeśli kompilacja powiedzie się, niż zatwierdzenie zestawu półek zostanie zatwierdzone, w przeciwnym razie nie zostanie zatwierdzone na serwerze Team Foundation Server. Daje to nieco lepszy obraz z kompilacji ciągłej integracji, ponieważ tylko udane zameldowanie może zostać zatwierdzone.

3. Wersje nocne: jest to również określane jako kompilacje zaplanowane. W takim przypadku planujemy uruchamianie kompilacji przez określony czas, aby utworzyć zmiany. Wszystkie poprzednie niezatwierdzone zmiany z ostatniej kompilacji są budowane podczas tego procesu kompilacji. Jest to praktykowane, gdy chcemy sprawdzać wiele razy, ale nie chcemy kompilacji za każdym razem, gdy sprawdzamy nasz kod, abyśmy mogli mieć ustalony czas lub okres, w którym możemy zainicjować kompilację w celu zbudowania zarejestrowanego kodu.

Więcej szczegółów na temat tych kompilacji można znaleźć w poniższej lokalizacji.

Budynki z zamkiem bramkowym

Kompilacje ciągłej integracji

nocne budowanie

Używałeś ich - IDE to narzędzie do budowania. W wierszu poleceń możesz użyć takich rzeczy jak make.

Ludzie używają narzędzi wiersza poleceń do takich rzeczy, jak nocne kompilacje - więc rano z kacem programista zdał sobie sprawę, że kod, którym majstrował przy najnowszych kompilacjach bibliotek, nie działa!

„... bardzo trudno jest śledzić, co należy zbudować” - narzędzia do budowania nie pomagają w tym wszystkim. Musisz wiedzieć, co chcesz zbudować. (Cytat z odpowiedzi Ritesh Gun)

„Słyszałem, że są używane prawie we wszelkiego rodzaju programach w świecie rzeczywistym” - Z jakiegoś powodu programiści lubią pracować w dużych firmach. Wydaje się, że mają bardziej niejasne wytyczne dotyczące pracy dla każdej osoby tam pracującej.

„Dlaczego nigdy ich nie potrzebowałem przez ostatnie cztery lata”. Prawdopodobnie dlatego, że jesteś utalentowanym programistą.

Pseudo, meta. Myślę, że narzędzia do budowania nie przynoszą żadnych naprawdę realnych korzyści. Ma tylko dodać poczucie bezpieczeństwa wynikające ze złych praktyk firmy, braku kierunku - złe przywództwo architektoniczne w oprogramowaniu, co prowadzi do złej faktycznej znajomości projektu. Nigdy nie powinieneś używać narzędzi do kompilacji (do testowania) w swoim projekcie. Wykonywanie losowych testów bez znajomości projektu oprogramowania nie daje żadnej pomocy.

Nigdy nie powinieneś dodawać czegoś do projektu bez znajomości jego celu i tego, jak będzie działać z innymi komponentami. Komponenty mogą działać osobno, ale nie współpracować. (To jest odpowiedzialność architekta oprogramowania, którego przyjmuję).

Co się stanie, jeśli do projektu zostanie dodanych 4-5 komponentów? Dodajesz szósty komponent. Razem z pierwszym dodanym komponentem może wszystko schrzanić. Żaden automat nie pomógłby to wykryć.

Nie ma innego skrótu niż myślenie myślenie.

Następnie jest automatyczne pobieranie z repozytoriów. Dlaczego miałbyś kiedykolwiek chcieć to zrobić? Musisz wiedzieć, co pobierasz, co dodajesz do projektu. Jak wykrywacie zmiany w wersjach repozytoriów? Musisz wiedzieć. Nie możesz niczego „automatycznie”.

A co by było, gdybyśmy przetestowali rowery i wózki dziecięce z zawiązanymi oczami kijem i po prostu przypadkowo nim uderzali. Wydaje się, że to jest idea testowania narzędzi do budowania.

Przepraszam, że nie ma skrótu https://en.wikipedia.org/wiki/Scientific_method i https://en.wikipedia.org/wiki/Analysis