Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Portal
  • |
  • Mitglieder
Beiträge von Gimmick
Thema: DataGrid: Einzelne Zellen einfärben
Am im Forum: GUI: WPF und XAML

Zitat von witte
Dann mache doch eine Liste von ViewModel-Objekten, eines pro Zeile, binde dort das Model und UI-Info dran und binde das in das Grid.

Ich habe das Gefühl, ich denke manchmal zu kompliziert x), merci.

Thema: DataGrid: Einzelne Zellen einfärben
Am im Forum: GUI: WPF und XAML

Hallo,

ich bin gerade dabei ein paar ältere Forms Programme neu zu schreiben und habe Probleme beim Einfärben der Datagrid Zellen.

Die Daten für das Datagrid kommen aus einer Ini-Datei und können beliebig aufgebaut sein. Alle Informationen für den Zell-Inhalt und die Zell-Farbe liegen als Koordinaten vor. Es gibt keinen direkten Bezug zwischen Zell-Inhalt und -Farbe.

In Forms konnte ich einfach die entsprechenden Koordinaten auslesen und die Farbe direkt den Zellen zuweisen.

Aber wie gehe ich denn da in WPF vor?

Aus den Daten der IniDatei baue ich mir zunächst ein Datatable (den Code habe ich beibehalten) und weise dann einfach über dataGrid.ItemsSource = DataTable.DefaultView den Inhalt zu.
Der DataTable enthält ja aber nur Informationen über die Daten, nicht über die GUI.

Ich stehe da ziemlich auf dem Schlauch, wie ich das DataGrid dafür idealerweise anbinde.

Thema: DLL mit mehreren UserControls anlegen, die ich über die Toolbox anlegen kann
Am im Forum: Grundlagen von C#

Zitat von Spook
Dann würde ich bei beiden Controls gegen das gleiche VM binden. Musst du doch eh machen, wenn diese auf die gleichen Daten zugreifen sollen.

Ja, das sollen nur idealer Weise die Controls selbst machen, so dass man Control1 und Control2 beliebig über die Toolbox einbauen kann, die Verknüpfung der Pärchen aber automatisch entsteht.

Ich habs jetzt erstmal so gemacht, dass man den Control über eine Methode schon noch sagen muss zu welchem Datenbestand sie gehören.

Thema: DLL mit mehreren UserControls anlegen, die ich über die Toolbox anlegen kann
Am im Forum: Grundlagen von C#

Zitat von Spook
Wieso erstellst du nicht ein neues UserControl das die Text- und ListBox enthält und dieses Control auf die "Datenbasis" zugreift? Damit kannst du die Daten an dieses Control binden und dann auch mehrfach verwenden.

Moin,

die einzelnen Controls können in unterschiedlichen Fenstern/Reitern liegen. Ich muss die schon trennen.

Thema: DLL mit mehreren UserControls anlegen, die ich über die Toolbox anlegen kann
Am im Forum: Grundlagen von C#

Nachdem ich einiges ausprobiert habe:

Wenn ich zwei Controls habe und beide auf die selben Daten zugreifen können sollen, muss ich die Datenklasse wohl oder übel statisch setzen.

Damit greifen aber alle Control1s und alle Control2s auf die selben Daten zu.

Ich würde jetzt noch eine Schicht darunter eine statische Klasse einbauen, die eine Liste über die nicht-statischen Datenklassen führt und den Controls über ihren Constructor einen festen Index zuweisen.

Muss ich aber wohl noch einen Finalizer einbauen, um den ganzen Kram mit zu entfernen, wenn das Control entfernt wird =/

Thema: DLL mit mehreren UserControls anlegen, die ich über die Toolbox anlegen kann
Am im Forum: Grundlagen von C#

Hallo,

ich möchte eine DLL erzeugen, die zwei oder mehr UserControls enthält, welche die jeweils gleiche "Datenbasis" haben und sich über die ToolBox einfügen lassen.
Gleiche "Datenbasis" soll z.B. heißen:
Eine Control enthält eine TextBox, das andere Control eine ListBox -> Das Control mit der TextBox zeigt immer die Anzahl der Elemente in der ListBox an.

Meine erste Frage wäre nun: Geht das überhaupt?
Ein neues Control ist doch eigentlich immer ein eigenständiges Object, woher soll die Verbindung zwischen den einzelnen Controls kommen?

Normalerweise hätte ich das ganze in einer eigenen Klasse umschlossen, sodass die Controls nur zur Laufzeit hinzugefügt werden können "Class1 Cl = new Class1" -> Cl.Control1 .... / Cl.Control2 ....

Dann kann man sich die Controls aber nicht im Designer hinziehen wie man es gerne hätte.

Zweite Frage wäre nun: Wenn das geht: Wie?

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Für einen Kurztest habe ich mal 300 Buttons direkt in ein Panel mit Autoscroll gepackt.
Scroll-Balken stockt nicht, aber die Anzeige der Buttons ist dennoch recht langsam. Zudem hängt auch hier nach ein paar Mal hoch-runter-scrollen auch systemweit die Eingabe.

Zitat von Th69
Sind die Bilder denn einmalig in den Speicher geladen oder lädst du diese immer jeweils von Platte nach?

Die Bilder lade ich einmalig.

Ich habe das Problem jetzt mal in sofern umschifft:

DLL:
- enthält Forms-Usercontrol mit Splitcontainer
- Splitcontainer enthält einen "ElementHost"

- WPF-UserControl mit Wrapper + ScrollViewer
- WPF-UserControl für die Buttons, Bildinfos und das Bild

Das UserControl mit dem Splitcontainer kommt dann in ein TabControl in der Forms-Anwendung.

Das ist ein "wenig" umständlich, läuft aber. Habe mal ~1000 Bilder geladen und die Darstellung war gar kein Problem.

Jetzt habe ich aber das Problem, dass die Optik der WPF-Controls anpassen muss, weil ich in Forms den "Flatstyle" nutze.
Ist aber mein erster Kontakt mit WPF, werde am WE vermutlich dazu mal einen eigenen Thread erstellen


Habt ihr das in Forms denn mal gegenprobiert?

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Zitat von witte
Wie groß sind die Bilder? Du hast was von Vorschau geschrieben ... Nicht dass das nicht klappt und die Hütte Gigabytes schaufelt?

Moin,

die erste "Komplett-Testversion" hat 150*150 px Bilder in die Controls gezeichnet, die letzten Kurztests haben gar keine Bilder gezeichnet, nur die 3 Buttons.

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Zitat von Th69
Da muß es noch eine andere Ursache geben, daß es beim Scrollen hängt.

Bei meinen Spieleprojekten verwende ich auch öfters selbstgezeichnete Controls (inkl. JPG-Bildern) in Panels mit Scrollbalken (und konnte bisher nie eine Verlangsamung feststellen - auch nicht bei mehreren 100 Elementen).

Das ist jetzt evtl. ein Missverständnis, für den Test habe ich einfach ein UserControl mit 3 Buttons per Schleife 100 mal in die Controls des flowlayoutpanels gepackt.

Hab das gerade nochmal auf einem anderen Rechner probiert. Die Kiste hat etwas mehr Hubraum - da stockt erstmal nichts, aber auch hier sieht man wie sich die Controls aufbauen / gestreckt dargestellt werden und wenn man mehrmals hoch-runter-scrollt braucht das System (also auch Windows außerhalb des Programs) ein paar Sekunden bevor überhaupt wieder Mauseingaben funktionieren.
Zitat
Für das Selberzeichnen von Standard-Steuerelementen gibt es die entsprechenden Renderer-Klassen, z.B. ButtonRenderer (dies sehe ich aber als allerletzte Möglichkeit zur Optimierung).

Falls es aber zu Flackern kommt, dann hilft [Artikel] Flackernde Controls und flackerndes Zeichnen vermeiden.

Ok, danke, schaue ich mir auch mal an.
Habe auch mal über den ElementHost ein WPF-Warppanel in ein Forms gepackt. Auf den ersten Blick lief auch das ganz gut. Im Detail habe ich mir das aber noch nicht angesehen.

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Hallo.

Zitat von witte
* versuche mal durch Verringern der Controls rauszubekommen warum das so lange dauert, wer also der Störenfried ist. Also was du im Code gemacht hast auch auf die Controls anwenden.

Habe schon ein Testprojekt erstell, dass einfach nur ein UserControl mit 3 Buttons x-mal in das Panel packt. Es steht und fällt mit Größe des Fensters, bzw. vermutlich eher mit der Anzahl der gleichzeitig sichtbaren Controls im Panel.
Da hängt beim Scrollen einfach alles.
Zitat
* im WPF gibt es virtuelle Container, z.B. VirtualStackPanel. Diese generieren Elemente erst wenn sie sichtbar werden. Google mal ob es Ansätze/Codebeispiele/Controls für WinForms existieren dann brauchst du das Rad nicht neu erfinden.

Wie intern die Elemente gehandhabt werden weiß ich nicht. Es kann aber auch an der Zeichengeschwindigkeit liegen und in dem Fall wird selber alles Zeichnen den Braten nicht fett machen. Gerade wenn man scrollt und dann immer alles neu zeichnen... ich seh schon die Flackerhölle vor mir.

Habe auch gerade mal das Ganze in WPF mit einem Wrappanel nachgebaut (einfach ScrollViewer + Wrappanel + 200 UserControls) -> scrollt ohne Probleme.

Der Plan war die Galerie über eine DLL in ein bestehendes Form-Programm einzubauen, wenn ich dafür jetzt WPF nutzen würde, hätte ich dann durch die Mischung mit Problemen zu rechnen? Oder bremst evtl. das langsamste Glied der Kette und WPF in Forms ist genauso lahm wie Forms alleine?

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Zitat von Th69

Die langsamere Performance beim Scrollen wird aber wohl eher an dem FlowLayoutPanel sowie der Anzahl der eingefügten Elemente liegen - evtl. müßtest du diese auch selber zeichnen (und die Positionen berechnen).

Dazu hätte ich einige Fragen:

Was bedeutet in dem Fall "selber zeichnen"? Ich verstehe das so, dass ich dann das FlowLayoutPanel rauswerfe, eigene ScrollBars einfüge und anhand der Scrollposition für jedes Bild schaue:

1. Wo liegt es
2. Was sehe ich davon

Und dann entsprechend einzeichne.

Aber wie mache ich das mit nutzbaren Controls wie Buttons?
Kann ich evtl. mein UserControl so lassen wie es ist, das Control als Bitmap zwischenlagern und dann in der Zeichenfläche die Mausposition gegen jede errechnete Control/Bild-Position gegenchecken, den Klick abfangen, den Button in den pressed-Zustant setzen -> neues Bild generieren und das einzeichnen?
Oder im Worstcase das Usercontrol als Sammlung an Controls und Koordinaten speichern und nur den Button neu zeichnen?

Da müsste man dann wohl am besten noch eine Listung sichtbarer Objekte führen, damit nur da geprüft wird, wo auch geklickt werden kann.

Klingt aufwendig, oder denke ich zu kompliziert?
Zitat von Th69
GDI-Objekte, wie Brush, Pen o.ä. sollten immer wieder sofort nach Benutzung freigegeben werden (also entweder per Dispose oder aber besser gleich eine using-Anweisung benutzen).

Bei festen Farben reicht es aber direkt auf die Brushes- bzw.Pens-Klasse zuzugreifen:


SolidBrush brush = Brushes.White;
so daß nicht jedesmal ein neues temporäres GDI-Objekt erzeugt wird (und wieder freigegeben werden muß)!

PS: Auch die beiden fixen Rectangle könntest du als static readonly-Klassenmember einmalig erzeugen...

Da hast Du absolut Recht, ich wurschtel das Anfangs meistens erstmal so rein und räume später auf, wenn klar ist wohin die Reise überhaupt geht ^^.

Thema: Bildergalerie - flowlayoutpanel zu langsam
Am im Forum: GUI: Windows-Forms

Hallo zusammen,

ich tüftel gerade an einer Bildergalerie, die neben der Anzeige eines Vorschaubildes noch mehr Funktionen bieten soll und stoße dabei auf ein Performanceproblem.

Bisher hatte ich es so aufgebaut:

- Auswahl mehrerer Bilder mit blauem Rahmen als optisches Feedback
- Ein seletiertes Bild ist das "Hauptobjekt", angezeigt durch einen zusätzlichen orangenen Rahmen
- zu diesem Hauptobjekt werden in einem Datagrid diverse Infos angezeigt
- Unter jedem Bild befinden sich Buttons: Als "Hauptobjekt" auswählen, Entfernen, Originalbild öffnen
- Über jedem Bild ist eine Checkbox, um die Bilder einer Auswahl hinzuzufügen
- Unter jedem Bild sind zwei label für Dateinamen + Datum

Gebaut hatte ich das folgendermaßen:

Das UserControl enthält die Buttons, Checkbox und label. Das Vorschaubild und die Rahmen zeichne ich direkt in das Control.
In das flowlayoutpanel werden die UserControls eingefügt
Das flowlayoutpanel befindet sich dann zusammen mit dem Datagrid in einem SplitContainer

Funktional ist bisher alles super, aber man merkt einfach, dass es bei ~30+ Bildern unglaublich träge wird. Das Scrollen stockt dann und bei Änderung der Fenstergröße hängt die Galerie deutlich nach.

Das Zeichnen erledige ich im Paint-Event des UserControls:


        private void DrawImage(Image Bild, Graphics G)
        {
            G.DrawImage(Bild, new Point(_StartX, 15));
        }

        private void DrawSelection(bool Val, Graphics G)
        {
            if (Val)
            {
                SolidBrush brush = new SolidBrush(Color.LightBlue);
                G.FillRectangle(brush, new Rectangle(5, 5, 190, 170));
                _paintedBlue = true;
            }
            else if (!Val && (_paintedBlue || _paintedOrange))
            {
                SolidBrush brush = new SolidBrush(Color.White);
                G.FillRectangle(brush, new Rectangle(5, 5, 190, 170));
                _paintedBlue = false;
                _paintedOrange = false;
            }
        }

        private void DrawMainSelection(bool Val, Graphics G)
        {
            if (Val)
            {
                SolidBrush brush = new SolidBrush(Color.DarkOrange);
                G.FillRectangle(brush, new Rectangle(15, 10, 170, 150));
                _paintedOrange = true;
            }

        }

        private void LargeGallery_Image_Paint(object sender, PaintEventArgs e)
        {

            DrawSelection(_Selected, e.Graphics);
            DrawMainSelection(_Mainselection, e.Graphics);
            DrawImage(_Bild, e.Graphics);

        }

Auskommentieren der einzelnen paint-methoden macht es schneller, aber ehrlichgesagt ist es selbst ganz ohne Bild und Rahmen, nur mit den Buttons etc., auch schon zu langsam beim Scrollen.

Habt ihr einen Vorschlag, wie man das besser umsetzen könnte?

Thema: Chart: horizontale Linie auf Balken
Am im Forum: GUI: Windows-Forms

Meine "Lösung":


int NumberOfPoints = chart1.Series[0].Points.Count;
double width = chart1.ChartAreas[0].innerPlotPosition.Width * chart.Width / 100;
double PointSpace = width / NumberOfPoints / 2;

chart1.Series[0].SetCustomProperty("PixelPointWidth", ((int)PointSpace).ToString());
chart1.Series[1].SetCustomProperty("PixelPointWidth", ((int)PointSpace).ToString());


Series[0] enthält die Datenpunkte für die Balken
Series[1] enthält die Datenpunkte für die Linien in Form von Fehlerbalken, wobei die drei Y-Koordinaten einfach identisch sind :D.

Die Breite der Fehlerbalken musste nur angeglichen werden.

Thema: Chart: horizontale Linie auf Balken
Am im Forum: GUI: Windows-Forms

Hallo,

ich würde gerne in mein Balkendiagramm (edit: "Column") horizontale Linien zeichnen, die genau in den Balken liegen.

Dafür brauche ich aber die Koordinaten der Balkenränder oder zumindest die Dicke der Balken, die Koordinate der DataPoints kann man ja abfragen.

Ich finde dazu aber nur die CustomProperties:

PointWidth für den Abstand der Balken

und

PixelPointWidth für die Breite der Balken

Wenn ich die benutze, müsste ich mir aber selber überlegen wie ich die Abhängigkeit der Werte zur Chart-Breite und Punkt-Anzahl setze.
Das möchte ich mir eigentlich sparen.

Kennt jemand evtl. noch eine andere Möglichkeit die Linien umzusetzen?

edit2: Bildanhang; Mit Paint gemalt.

Thema: Performance von Blend-Effekt von einem Bild ins andere verbessern
Am im Forum: Grafik und Sound

Gute Sache, danke fürs Posten

Thema: Suche Bibliothek oder Algorithmus um Bildeffekte schneller anzeigen zu lassen
Am im Forum: Grafik und Sound

Wenn das Bild auch in voller Auflösung 1:1 sichtbar sein kann, ist das natürlich blöd.

Wenn es sich aber um hochauflösende Fotos handelt, würde ich dennoch (evtl. in Abh. der Monitorauflösung) ein Dummybild erstellen, zwischen 2 MP und 45 MP gäbs dann doch schon noch einen Unterschied ^^.

In Bildbearbeitungsprogrammen gibt es ja auch immer eine Vorschau, das hat schon seinen Grund ;).

Thema: Performance von Blend-Effekt von einem Bild ins andere verbessern
Am im Forum: Grafik und Sound

Schau mal hier für das Prinzip:
https://code.msdn.microsoft.com/windowsapps/Blending-Bitmap-2922c196

Wenn das Überblenden nach Schrittzahl gehen soll, könnte man die Schrittweite pro Pixel getrennt hinterlegen und so noch minimal Rechenzeit sparen, soll das Überblenden nach Zeit gehen, müsste man die Schrittweite zumindest nach dem ersten Schritt anpassen.

Ansonsten könnte man auch hier wieder ein bissl lügen und betrügen und z.B. nur jeden zweiten Pixel abwechselnd ändern.

Thema: Suche Bibliothek oder Algorithmus um Bildeffekte schneller anzeigen zu lassen
Am im Forum: Grafik und Sound

Ich kann nur aus Erfahrung mit diversen Bildbearbeitungsprogrammen sagen, dass die Filter immer ihre Zeit brauchen.

Bei der ColorReduction könnte man schauen, ob es verschiedene Dither-Methoden gibt, die dann evtl. etwas schneller sind.

Wenn Du von eienr Diashow sprichst, klingt das danach, dass eine Reihe von Bildern nach und nach angezeigt werden. Da könnte man zum Kaschieren der Rechenzeit ja schon im Vorraus anfangen zu Rechnen.

Und je nach Aufteilung der Bildanzeige, also Original, farbreduziert und mit ölfilter, benötigst Du ja eventuell auch nicht die volle Auflösung der Bilder.

Thema: OpenGL für WinForms mit Intel HD Grafik
Am im Forum: Grafik und Sound

So ganz klar ist mir die Methode ehrlichgesagt nicht.
Du hast in Deinen FillRectangel()-Aufrufen dem Namen nach immer eine Farbe und eine zoom-abhängige Höhe/Breite als Parameter. Heißt das, dass du für jeden Wert aus deinen Rohdaten ein einfarbiges Rechteck zeichnest?

Ein ganzes Bitmap zu zeichnen geht deutlich schneller.

Ich würde sowas machen wie:

1. Über Scrollposition und Zoom die Größe und Position des "Datenfensters" bestimmen.

2. Über Höhe*Breite*3 ein 24bpp 1D-Array erstellen

3. Die Daten aus dem Fenster Farben zuordnen, in das Array schreiben und das Array über irgendeine Methode auf die Ausgabe skalieren (nearest neighbor evtl. da findet man auch gut was zu).

4. Die Daten aus dem Array in das Bitmap schreiben (z.B. mit Marshal.Copy/Lockbits)

5. Bitmap Anzeigen in Picturebox oder direkt zeichnen mit drawImage.


Wenn ich das richtig verstanden habe werden nicht die gesamten Daten mit 25Hz erneuert, sondern alle 40ms kommt eine neue Zeile und die alten Daten werden nach und nach überschreiben? Man könnte dann ja auch Scheibchen-Bilder erstellen oder einen TextureBrush benutzen, müsste man wohl ausprobieren.

Thema: OpenGL für WinForms mit Intel HD Grafik
Am im Forum: Grafik und Sound

Was meinst Du denn mit "komplex"? Die Größe des Bildes oder wird der Inhalt des Bildes erst berechnet und das dauert?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Nur mal ein Update:

Die Arbeit mit einer Kombination aus Gitlab und Redmine hat sich bisher bewährt. Eure Posts haben sehr geholfen, danke.

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von Abt
Doch. Dafür hast Du ja Dein Git Repository.
Und ein Release ist immer mit einem Git Commit getaggt.

Achso, ich dachte das würde immer überschrieben werden.
Zitat
Das Grundproblem ist meiner Ansicht nacht immer noch, dass eure internen Prozesse mit einem modernen DevOps Prozess und den Mechanismen in einem Release System nicht im Einklang stehen.

Davon abgesehen, dass dies kein roter Faden durch DevOps wäre: das Ergebnis wäre aber kein deterministisches.
Das gilt es in DevOps zu vermeiden.

Ne, das ist nicht das Grundproblem.

Es geht hier ja rein um das Verständnis des vorgesehenen Prozesses und vorallem um die reale Umsetzung davon mit Git - von null. Was muss ich wo einstellen, was macht die Pipeline konkret und wie sieht der tatsächliche Release-Prozess aus. Der reale Prozess hat damit erstmal nichts zu tun.
Das Zusammentreffen mit der Realität folgt erst noch.

Ich finde die ganze Sache schon rein von den Begriffen verwirrend.
Der Hinweis mit den Tags war gut.

Ich muss jetzt mal Zeit finden und mein Gitlab nach den Prinzipien einstellen. Dann wieder im Kleinen testen.

Ich seh die Probleme bei der Pipeline schon - ich melde mich dann :D.

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von gfoidl
Der Quellcode ist "neutral". Die Anpassung an die Environment passiert via Konfiguration.

Drück es umgehrt aus: aus dem Masterbranch wird ein Artefakt (Komponente, Anwendung, ...) erstellt und dieses Artefakt wird an die Environments wie Dev, Test und Prod weitergereicht (ohne dabei verändert zu werden, siehe Konfig).

In dem Fall hätte man aber kein Backup des Codes, aus dem der aktuelle Prod-Stand erstellt wurde.

Zitat von Palin
Hi Gimmick,

um es vielleicht mal mit einem anderen Ansatz zu erklären.

Die willst 3 Quellcode Branchen hab. (Dev, Main, Release)

[...]

Dann kannst (musst aber nicht) du für alle 3 ein Dev, Test und Release Environment haben.

[...]


Erstmal danke für den umfangreichen Post.

Wenn ich nicht jeweils drei eigene Environments hätte, müsste ich aber in der Pipeline prüfen, in welchem Branch ich gerade bin, damit das Main-Artifact nicht nach dem Prod/Release-Release-Prozedere veröffentlicht wird.

Und das meinte ich damit, dass die Environments ja quasi von den Branches wissen müssen.

Wenn ich hingegen drei Branches anlegen, würde ich ja doch mein Release über die Branches oragnisieren - und darf man doch nicht ^^.

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Danke für die Grafik.

Zitat von Abt
Nein, generell macht man eigentlich nur ein Release auf den master Branch; nur in besonderen Ausnahmen auf Pull Requests.

Das Deployment auf Dev passiert i.d.R. mit einem automatisch Trigger.
Das bedeutet, sobald der master Branch erfolgreich gebaut wurde, wird das Artifact auf Dev deployed.

Wenn der Entwickler dann mit Dev zufrieden ist, dann erfolgt ein manuelles Deployment auf Test.
Wenn er damit ebenfalls zufrieden ist (bzw. wird Test zB verwendet, dass jemand anders als der Entwickler testen kann, zB der Kunde) dann erfolgt das Deployment auf Produktiv.
Das Artifakt dabei wird selbst NICHT neu erzeugt (sofern möglich).

D.h. der Quellcode wird garkeinem Environment zugeordnet, die Zugehörigkeit basiert rein darauf, dass der Masterbranch zum aktuellsten Deployment gehört, egal ob Dev, Test oder Prod?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Aber die Stages wissen schon von den Branches/einem Branch?

Ich kann ja dann beliebig viele Feature Branches aufmachen, meine Pipeline drüber laufen lassen und jeder Branch wird nach den Variablen des Environments z.B. intern Released - der Master Branch würde aber dennoch gesondert behandelt werden, weil ein Environment für andere Branches gar nicht erreichbar wäre?

Und die Feature Branches könnte man über "merge" dann zusammenführen, die einzel-Branches + ausgelieferte Dateien löschen?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von Abt
Prinzipiell nein.

Na super .
Zitat
Es gibt nur ein einziges Artifakt.
Nur das Release bestimmt, wo dieses Artifakt hin kommt - es gibt nur eines für alle Stages
(Es gibt aber Ausnahmen, die Technologiebedingt sind, sodass ein Artifakt nur auf einer Stage funktionieren kann; mobile Applikationen und Settings (zB Beta App soll auf eine andere API zugreifen als die produktive Version. Hier gibt es dann wirklich ein Artifact pro Stage - aber da kommen wir nun in spezielle Bereiche).

Gut, okay. Wenn die Prozedur das Artifakt entprechend verteilt, existiert in dem Git-Projekt nur ein Artifakt, aber ein neues Test-Release löscht ja nicht das alles vom Prod.-Release.
Zitat
An für sich kommen die Settings vom Environment und sind nicht Teil des Artifakts.
Dadurch kann ein Artifakt unverändert in allen Environments agieren.
Diese Art und Weise ist auch die am Höchsten gültige - gibt aber wie gesagt Ausnahmen.

Ein "Merge" findet überhaupt nicht statt; bzw. schafft mir das Wort derzeit Probleme, was Du meinst.
Denn Merge ist ein reservierter Begriff in der Quellcode-Verwaltung bzgl. dem Arbeiten von Branches. Und die Quellcode-Verwaltung kennt die Stages nicht.

Wa..?

https://gitlab.cern.ch/help/ci/environments.md

Die Stages sind doch die Schritte der Pipeline oder nicht?
Ich habe drei Branches: Alpha, Beta, Prod
Außerdem drei Stages: test, build, deploy
Und zwei Environments: Intern, Extern

Bei jedem Push in jedem Branch läuft die Pipeline an -> und abhängig vom Branch werden doch dann im deploy-stage die Parameter aus dem Environment geladen und entsprechend released?

Also hätte ich oben statt "merge" "push" schreiben sollen?
Zitat
Bzgl. dem Pflegen von Releases verlassen wir nun Theorie und Praxis von CI/CD Pipelines :-)
GitLab unterstützt ein wirkliches Release Management nicht. Nur Azure DevOps hat derzeit ein solches sauberes, getrenntes System für koordinierte Releases (wobei Atlassian auch auf einem guten Weg dazu ist).
In GitLab muss man das tatsächlich im YAML definieren (wie auch bei AppVeyor und Co).

Ich hab nur teilweise das Gefühl, die ganze Konfiguration pro Projekt länger dauert, als das eigentliche Projekt :D.

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von Abt
Dieses Artifact landet dann auf einem sogenannten Artifact Staging (Directory).
Das ist ein Ort, an dem von jedem Build die Resultate abgelegt werden - darauf hat niemand, absolut niemand Zugriff - ausser ein Release System.

Daher:
- Build erzeugt das Artifact
- Release verteilt das Artifact

Wenn Du also das Artifakt anderen zur Verfügung stellen willst: dann über ein Release.
Das Release kann auch eine E-Mail versenden, irgendwas auf ein FTP kopieren: alles.
Das muss alles pro-aktiv durch Deine Definition passieren. Es gibt kein DevOps Portal das dafür gedacht ist, dass hier irgendwelche Leute durch einen "Artifact Store" klicken.

Ein Release kann aber auch durchaus eine eigene Applikation starten, die dann zB automatisiert irgendwelche Dokumente zusammen packt und zur Verfügung stellt.

Ja genau so habe ich mir das gedacht. In meinem Vokabular waren nur Build, Release... kein Vorgang oder Prozess, sondern die Datei - mea culpa.

Der Release bei uns wäre dann das Ablegen auf einem Server sowie das Anhängen der Dateien an ein Projekt (im Sinne eines Projektes in Redmine), damit sich niemand durch den Server wühlen muss.

Zitat
Mir ist noch unklar, woher diese Dateien komme, wo diese Dateien abgelegt und verarbeitet werden - aber irgendwie hört sich das für mich danach an, dass dafür die Quellcode Verwaltung nicht der richtige Ort ist...?!

Wir nähern uns, ich spür's!

Genau, das soll nicht in die Quellcode-Verwaltung.
In die Quellcodeverwaltung soll:
- Der Quellcode
- Von mir geschriebene Doku dazu

In die Projektverwaltung (Redmine, Jira..) soll:
- Pflichten/Lastenhefte
- Installations-Doku
- Anwedungsbeschreibung
- Kompatibilitätslisten
- Projektdauer
-....
- Bei Sonderlösungen auch die "Artifacts".


Heisst also bspw.:

Ich arbeite in "dev" und merge nach "Test". Es findet ein Test-Build für das Test-Artifact statt und dieses wird nach Test-Release Regeln Released/Verteilt.

Ist damit alles dufte, wird Test nach Prod gemerged und das Prod-Release verteilt das aktuelle Test-Artifakt den Vorgaben entsprechend.

Also müssen meine Dev- und Test-Pipelines über einen Runner das Artifact erzeugen und verteilen.

Die Prod-Pipeline verteilt nur das Test-Artifact.

Wenn also jemand außer mir der Ansicht wäre, dass der aktuelle Teststand der neue Masterstand werden soll, schickt er ein Merge-Request raus.


Und dieses ganze Kompilieren, Verschicken, Verschieben läuft in GitLag über die .gitlab-ci.yml?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von Abt
Dann hast Du den enormen Benefit noch nicht entdeckt ;-)

:tongue:

Mööööglicherweise!

Ich weiß auch nicht, was da genau alles möglich wäre. Gerade im Bezug auf GitLab und die unterschiedlichen Ausstattungstufen.

Kannst Du eventuell ein wenig aus deinem Alltag schreiben, damit ich eine Vorstellung von einem "typischen" devops-orientierten Workflow bekomme? Denn bis auf die deutlich bessere Versionsverwaltung sehe ich jetzt nicht so unbedingt den riesen Vorteil. Es schreiben nicht mehrere Leute an einem Code oder sowas.

Azure Test Plans mal außen vor gelassen, den Vorteil sehe ich .
Zitat
Von was für Dokumente sprechen wir? Ein Quellcodeverwaltungssystem ist kein ordentlicher Platz für Dokumente im Sinne der Kollaboration.
Zudem brauchen Stakeholder nie(!) Zugriff auf Builds!
Worauf brauchen Sie denn beim Build Zugriff, auf Artifacts? Oder was meinst Du mit "Build" ?

Ja das wären dann wohl Artifacts. "Dat was beim Kompilieren hinten raus kommen tut".
Beispiel wäre:
Kunde hat ein Gerät, dass wir nicht in unserem Standardrepertoir haben. Ich würde das anbinden und beim Einrichten der gesamten Messstation müssen dann eben noch Dateien ergänzt werden.

Die Dateien + Informationen darüber sollen irgendwo übersichtlich zur Verfügung stehen.

Das meinte ich auch mit "Sonderlösungen".
Zitat
Willkommen im Jahr 2018 :-)

Ich weigere mich!
Zitat
Jira ist nur ein Bug Tracking System - für Build und Co hat Atlassian andere Produkte.
.. und das kann kein Tool abdecken.
Tools wie VSTS, Jira, GitLab und Co orientieren sich an etablierten Prozessen in der Software Entwicklung - nicht an Sonderlösungen bzw. historisch gewachsene Prozesse ;-)

Jira ist doch auch ein Projektmanager im Sinne des Planens und Verwaltens.

Eventuell ja eine Kombination aus Gitlab und damit verbundenem Redmine?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

So richtig weiter komme ich bei meiner Umstellung leider nicht.

Die reine Verwaltung von Code für ein Projekt in Gitlab mit Branches, Übersicht über die Commits und dem Bugtracker gefällt mir zwar gut und schafft ja auch Übersicht, aber alles weitere erscheint mir doch als Overkill und unnötig kompliziert.

Für Teams, die wirklich gemeinsam an einem Projekt arbeiten mag das ja alles gut sein, für mich scheint die ganze CI/CD Geschichte aber eher Arbeit zu erzeugen, als zu sparen.

Zudem fehlt mir die gewünschte Schnittstelle zu Personen außerhalb der Entwicklung. Issues anlegen per Mail ist zwar schon ganz praktisch, aber es fehlt die Zugänglichkeit zu den eigentlichen Dokumenten und Builds.
Wir haben hier auch oft Sonderlösungen, die vor Ort eingerichtet werden müssen, da soll direkt über das Projekt in der Verwaltungssoftware alles Notwendige ersichtlich sein.

Ich habe mir auch Azure angesehen, das ist schon eine schöne Sache ;)
Allerdings schwierig im Alltag auszuprobieren, es soll nichts in die Cloud.

Vielleicht sollte es mehr Richtung Jira gehen?

Thema: Empfehlung für die Verwaltung von Softwareprojekten / Projektmanagement
Am im Forum: Smalltalk

Zitat von Abt
"Development" Branch hört sich nach einem GitFlow an - ein Ansatz, der eher zu Wasserfall-Projekten passt.
Schau Dir bitte den GitHubFlow an.

Mach ich.
Ja meine Arbeit ist definitiv nach dem Wasserfallmodell. Ob das Gesamtpaket aus diversen Modulen dann noch unter Wasserfall fällt, weiß ich nicht. Wohl eher eine Mischung.
Zitat von Abt
Auch das ist wohl eher Wasserfall.
Modern würde man Variationen via Feature Flags umsetzen.

Ja, geht nur nicht überall, bzw. an einigen Stellen würde das grundlegende Änderungen erfordern und das wird geschoben...
Zitat von Abt
Je nachdem was hier "Daten" sind kann das das Prinzip von DevOps verletzen - oder nicht.
Was soll hier passieren?

In dem Beispiel sollte das fertig kompilierte Plugin zum Gesamtpaket der Anwendung kopiert werden.

Zitat von Abt
... dass Du erst mal eure aktuellen Prozesse evtl. infrage stellst..? ;-)
Es hört sich vieles bei Dir / euch danach an, dass eure Prozesse nicht unbedingt einem modernen, etabliertem Arbeitsumfeld in der Software Entwicklung entspricht, sondern viel "historisch gewachsen" ist.
Das ist prinzipiell "nicht schlimm"; ich treffe auf viele solcher Umgebungen - aber man muss es halt mal gerade ziehen, bevor es dann wirklich explodiert.

Die Ausrede (die ich zumindest öfter höre), dass man es nicht anders machen kann, weil man keine Tools findet, die gewachsene Prozesse abdecken; das ist aus meinen Augen eher ein Eingeständnis ;-)

Da bin ich ja gerade dabei.
Hier entspricht überhaupt nichts dem Modell eines modernen Entwicklungsprozesses. Ich bin hier relativ neu und merke nur einfach, dass für mich das bisherige System extrem anstrengend ist und ich dabei bin den Überblick zu verlieren wer wie wo was wann... ;)
Die Kollegen haben das Problem nicht, sind aber offen für Änderungen.

Ich bin allerdings kein Informatiker oder IT'ler sondern schnöder Physiker. Die ganzen Entwicklungsprozesse sind unbekannten Terrain. Von daher ist es mir eigentlich auch relativ egal wie der Prozess am Ende aussieht, hautpsache es hat Struktur.
Zitat von Abt
Ein Build darf niemals den Code verändern. Der Code ist auch die völlig falsche Stelle für das Tracken von Bugs oder fehlgeschlagenen Tests.

Ein automatisch Bug kann erzeugt werden - und je nach Programmiersprache kann natürlich der dazugehörige Test im Bug direkt verlinkt werden.
Es kann aber natürlich nur der Test selbst verlinkt werden und nicht "jede" Codezeile (zumindest VSTS kann das).

Ich meinte aber eher händische Nutzertests und keine Komponententests. Kann man die ausgeführten Aktionen vielleicht loggen?