[Selbständigkeit] Welches Setup aufsetzen

[moep.at]

Servus Zusammen,
hoffe das passt thematisch hier rein, ansonsten bitte verschieben - danke!


ich mache mich mit Juli Selbständig.

Jetzt habe ich noch einige offene Punkte bzgl meines Setups.

Wie würdet ihr das machen?


Was hätte ich gerne:
- Zugriff auf meine Daten von überall --> Freigaben für den Kunden wäre nice to have (ansonsten teilen wir jetzt auch schon Projekte via Wetransfer)
- git Server (kleine Projekte, nur ich arbeite dran)
- Office


Ich werde zu 90% auf meinem Laptop arbeiten, 10% an Rechnern von Kunden wo ich mittels USB-Stick die Daten dann auf mein System sichern würde.

Ich hab an Office 365 gedacht mit OneDrive, da gits ja dieses 1TB Paket... denke damit komm ich gut über die Runden.
Damit müsste ich ja schonmal ziemlich viel erschlagen können, Zugriff auf all meine Daten, von überall egal welche Größe. Auch "teilen" geht damit ja recht einfach.

Aber was mach ich mit git?
Kann ich das soweit "lokal" laufen lassen und nur den Folder halt spiegeln? Geht eigentlich nur um die Historie und Dokumentation der Commits.
Es arbeite eh nur ich an den Projekten, geteilt werden maximal definierte kompilierte Version oder eben ein definierter Stand X.


Ich bin für alle Vorschläge/Inputs offen

Danke schon mal!

 

[p4n0]

Heyho,
an deiner Stelle wuerde ich warscheinlich was kleines auf Azure anstreben.
Nen Tenant mit wenig (1-10) Usern kostet nicht die Welt und du kansnt auch gleich Compute und Storage dort nutzen.
On Top bekommst du gleich nen AD dazu, was dir im spaeteren Verlauf helfen wird.
Git regelst du entweder Schmalspur per Azure DevOps inkl. Pipelines oder halt gesondert per Github. Der Kram laesst sich wundervoll miteinander verheiraten.

Zu Hause wuerde ich mir warscheinlich nur was hinstellen wenn der Rest schon da ist (Also Server, Netzsegmente etc..) Weil du willst den Kram von Privat getrennt haben.

 

[sandreas]

- git Server (kleine Projekte, nur ich arbeite dran)

Warum brauchst du denn dann einen Server, wenn nur du dran arbeitest? Git ist doch darauf ausgelegt, dass man es lokal nutzen kann.

 

[p4n0]

Und wo soll sein Code herumliegen und wo sollen seine Pipelines laufen? N Git Client ist ja nur die haelfte der Angelegenheit…

 

[sandreas]

Und wo soll sein Code herumliegen und wo sollen seine Pipelines laufen? N Git Client ist ja nur die haelfte der Angelegenheit…

Naja, für kleine Projekte mit einer Person nen CI server mit SonarQube aufzusetzen halte ich für ein wenig Overkill ... auch wenns nett ist.

Aber mit Lokalem Git und Docker kommt man schon ziemlich weit, wenns nicht github oder codeberg sein soll.

 

[moep.at]

Danke.

Mir war nicht ganz klar ob ich das eben nur lokal laufen lassen kann oder eben nen Server brauche

Wenn das so geht ist das doch genau das was ich will

Lokal arbeiten, commit usw alles möglich und eben auch einfach mit OneDrive synchen... dann hab ich meine Historie und kann vor/zurück springen



Sry, ich nutze zwar git täglich,aber aufgesetzt ist es halt schon bei uns in der Firma. Musste mich bis dato nicht mit den Grundlagen auseinandersetzen 😅

 

[p4n0]

Naja, für kleine Projekte mit einer Person nen CI server mit SonarQube aufzusetzen halte ich für ein wenig Overkill ... auch wenns nett ist.

Genau deswegen kann man ja zB Azure DevOps nutzen. Sollte komplett ausrsichend sein, frisst kaum Heu und man muss sich nicht um den Betrieb kuemmern.

 

[LordAGo]

Sry, ich nutze zwar git täglich,aber aufgesetzt ist es halt schon bei uns in der Firma. Musste mich bis dato nicht mit den Grundlagen auseinandersetzen 😅

git init .

fertig.

 

[slikslak]

Hi,

erstmals Gratulation für die Selbständigkeit

Offtopic: Da du ja aus Österreich bis, hol dir die Digitalförderung, informier dich mal da, falls du es nicht getan hast

 

[uan]

Office? Raider heisst jetzt Twix, sonst ändert sich nix... ;-)

Wenn das mal ein bißchen Brief schreiben ist, vielleicht reicht das umsonstene Word im Browser? Excel und PP auch für umme.... Ist zwar ein wenig kastrierter Funktionsumfang (Serienbriefe zB) aber eben für umme. Für den täglichen Schriftverkehr völlig ausreichend und die fehlenden Funktionen werden sukzessive ergänzt.
Anmelden mit nem Microsoft Account und da, wo du nen Browser hast - haste auch deine Anwendungen. Ist schon praktisch...

Ganz ehrlich, 365 pfff, man muss ja nicht jeden Blödsinn mitmachen.

 

[flxmmr]

wo sollen seine Pipelines laufen

https://github.com/firecow/gitlab-ci-local -

Lokal arbeiten, commit usw alles möglich und eben auch einfach mit OneDrive synchen...

weiß nicht, wie gut der OneDrive-sync-Algorithmus ist. Tendenziell hört sich das nach etwas an, was ich lassen würde. Ich würde einen der vielen Git-Services nutzen, wenn dir ein Server mit SSH irgendwo nicht reicht (so einen Server könnte man dann vmtl. auch als Relay aus Unternehmensnetzen nutzen, solange du nichts anderes unterschreiben musstest ).

Ganz ehrlich, 365 pfff, man muss ja nicht jeden Blödsinn mitmachen.

Dann kann man aber auch gleich LibreOffice nehmen und einen Windows-Server mit RDP und einer Office-Kaufversion zur Konversion rumhängen lassen .

 

[pumuckel]

Die Datenschutzgrundverordnung - Your Europe

Erfahren Sie mehr über die Anforderungen für Unternehmen und Organisationen bei der Erfassung, Speicherung und Verwaltung personenbezogener Daten.

europa.eu

 

[moep.at]

Ich grab das jetzt noch mal aus

Es wurde jetzt mal die Office 365 Lizenz mit dem 1TB OneDrive.


Noch ne Frage zum sichern der Daten.
Gefühlt ist ein Server/NAS bisschen "Overkill" für mich.

Meine Idee wäre jetzt einfach ne externe SDD an meiner Dockingstation zuhause und eine an der Fritzbox zuhause. (2-4TB pro Platte, vlt auch ne große mechanische an die Fritzbox?)
Source will ich sowohl auf die externen Platten wie auch OneDrive spiegeln lassen --> sprich die lokalen git repos einfach kopieren

für unterschiedliche Kunden werde ich immer eine gesonderte virtuelle Maschine haben, leider ist LabVIEW (meine Entwicklungsumgebung) scheiße was das handling verschiedener Versionen und Plugins angeht.
Diese würde ich regelmäßig auf den externen SSDs sichern. Da gehts im Grunde nur darum keine Versions-Wirr-Warr zusammenzubekommen. (jeder Kunde verwendet nun mal unterschiedliche Setups)


Gute/Schlechte Idee? Bin ich am Holzweg?

 

[p4n0]

Aus meiner Sicht Holzweg.
Ab nach Azure. Dort bekommst du alles was du aktuell brauchst und hast Luft fuer die Zukunft.
Grad wenn's losgeht mit unterschiedlichen Kunden, Anforderungen an VM's etc..

Wir kennen deine Anforderungen nicht so recht aber was ich aus Erfahrung sagen kann:
Bau dir ein moeglichst automatisiertes Setup.

Sofern moeglich mit git und pipelines.
Buildagents wenn moeglich in Container packen. Somit hast du ein Setup was extrem flexibel mit
unterschiedlichen Versionen etc umgehen kann und immer alles ganz nachvollziehbar zu jedem Zeitpunkt
gebaut werden kann.

Sofern dein Entwickler-Setup solche Sachen zulaesst wuerde ich dir wirklich ans Herz legen diesen (anfangs sicher steinigen!!) Weg zu gehen.

 

[moep.at]

okay, ich glaube ich muss da etwas ausholen... mein Workflow und auch meine Tools sind da wohl etwas old school (sind einfach kacke in sehr vielen, modernen, belangen)


git: nutze ich nur um bisschen Historie und Doku zu haben. Es werden NIE mehrerer Entwickler dran sitzen.
VM: nur dazu da um jeweils ein Setup pro Kunde zu haben. Leider kann ich keine zwei Projekte an einem Rechner aufsetzen die unterschiedliche "Treiberversionen" verwenden. (Entwickeln ja, aber nicht kompilieren ohne den Kunden zu einem Update zu zwingen) Anforderung 16Gg RAM, ~300Gb Speicher und paar CPU Kerne (hab nen i7-1355u). Es werden auch keine zwei VMs gleichzeitig laufen, falls der wirklich seltene Fall mal vorkommen sollte nur um schnell was nachzusehen und die zweite wird derweil herumidlen...
kompilieren: das dauert auf meinem Laptop 10 Sekunden (bei einem großen Projekt)




so sieht gerade der Rechner beim Kunden aus, an dem ich gerade sitze.... "relativ viel offen", für meine Verhältnisse
(und hier rennen noch diverse Firmen überwachungszeugs usw mit rum... die wohl die meiste "performance" schlucken...)

 

[sandreas]

mein Workflow und auch meine Tools sind da wohl etwas old school

@p4n0 hat da schon ein bisschen recht. Jetzt hast du noch Zeit, dass alles einmal sauber einzurichten und dir Arbeit vom Hals zu halten. Später, wenn du Kunden hast, kostet dich das JEDES MAL unnötig Zeit.

Ich kenne dein Fachgebiet nicht (Kompilieren und Treiber + der Screenshot klingt nach Windows Umgebung mit einer kompilierten Sprache), aber:

• Der OneDrive-Sync ist ne schlechte Idee - warum? Weil du, wenn du das git-repo aus versehen auf 2 Rechnern ausgecheckt hast und an beiden Änderungen machst, schreibt der dir dein repository einfach kaputt.
  • Wenn du sowieso den Code zu Microsoft hochlädst (OneDrive) dann kannste auch gleich private github Repositories anlegen oder Azure verwenden, sofern du damit nicht gegen deren AGB verstößt als Unternehmer. Da haste dann gleich github actions (zum Builden) und eine Zentrales repository + sogar ne Package-Registry oder halt bei Azure alles
• NIE und IMMER sind Wörter, die ich im Zusammenhang mit Projekten nicht verwenden würde.
• VM / Unterschiedliche Setups: Schon mal docker angeschaut? Wäre wohl Zeit.

Mein allgemeiner Rat: Bevor du diese Frickel-Lösung fährst, würde ich mir zumindest mal 5 Tage einplanen, in denen du dir anschaust, wie viel Zeit es braucht, um einen vernünftigen Workflow einzurichten und gegen rechnen, wie viel Zeit es dir umgerechnet pro Tag spart. Aber ein guter Workflow bringt noch mehr Benefits... professionelleres Auftreten, weniger Fehler beim Deployment, bessere Dokumentation, mehr Know-How.

Ein Beispiel: Ich habe mehrere Open Source Projekte bei Github. Früher gabs github actions noch nicht und ich habe immer manuell auf dem Laptop kompiliert, das Artefakt hochgeladen und die Release-Notes manuell hinzugefügt.
Bei einem neueren Projekt (https://github.com/sandreas/tone) habe ich es so eingerichtet, dass bei einem `git tag` automatisch eine Aktion läuft, die die Software für 8 verschiedene Architekturen kompiliert, in Archive verpackt, release-notes hinzufügt und das Release bei github erstellt. Alles vollautomatisch. Das spart immens Zeit und vermeidet Fehler.

 

[moep.at]

Danke schon mal.

Ich schau mir das die Tage mal alles an!
hab auf die schnelle 2-3 Artikel zu Docker in Kombination mit LabVIEW gefunden, aber auf die schnelle war da keine Begeisterung zu sehen :P

Docker hab ich zwar schon mal gehört, aber irgendwie kann ich mir das gerade bei LabVIEW nicht vorstellen. (das Teil frist sich so tief in Windows und nur in Kombinationen aus Treibern/LabVIEW)
Beispiel:
ich installiere LabVIEW 2018 UND LabVIEW 2023 UND ein Treiber Paket 2017 --> genau in der Reihenfolge
jetzt habe ich in beiden LabVIEW Versionen den Treiber 2017 zur Verfügung
Wenn ich jetzt LabVIEW 2024 installiere gibt es dort den 2017er Treiber nicht... man muss nun den Treiber deinstallieren und neu installieren damit er wieder in allen Versionen verfügbar ist.

Das klingt jetzt bei EINEM Treiberpaket nicht wild.. ich hab aber einen Kunden der zB 10 verschiedene Pakte in genau definierten Versionen auf Prüfplätzen ausgerollt hat.
Wenn ich jetzt wegen nem andren Kunden das ein update machen würde kann ich wieder alles deinstallieren und neu installieren um eben zwischen den Kunden hin und her springen zu können.
Deswegen meine Idee mit den VMs

Im Grunde ist auch der ganze Workflow mit LabVIEW gaaaanz anders als mit textbasierten Programmiersprachen.


@git: es wird definitiv niemals zwei Rechner(VMs) geben die am selben Code parallel arbeiten. --> aber ich verstehe das Argument mit "NIE und IMMER"... ich denk nochmal drüber nach.


Ich arbeite jetzt seit ~2008 mit LabVIEW, bisherige Setups, die ich gesehen habe, sowohl bei uns als auch bei Kunden:
- git, einmal monatlich wird halt eingecheckt (meistens nur bei Projektende oder Übergaben)
- ein Netzlaufwerk auf das alle paar Wochen mal ein .zip des Codes geschoben wird "20240621_StatuX.zip" oder "20240621_Übergabe01.zip"

Von irgendwelchen Build-Servern usw brauchen wir erst gar nicht reden anfangen... die maximalste "Automatisierung" die ich gesehen habe war das via Batch-Script generieren von diversen Installern, nach einem neuen Release

 

[sandreas]

LabVIEW

Kenn ich nicht - nie genutzt. Es scheint aber, als wäre docker hier nicht die richtige Wahl. Vielleicht dann in dem Fall Ansible oder Terraform oder sogar AutoIT mal ansehen.

Deploying LabView through Ansible

Hey all, I'm trying to deploy LabView on a target system but seem to be coming across an issue when deploying through Ansible. I'm trying to deploy LabView 2019 S1 f5 (ni-labview-2019-x86_19.1.5_offline.iso) that uses NI Package Manager (NIPM) 20.5.0. I'm using the command: `Start-Process...

forums.ni.com

Ansonsten bei den VMs bleiben, das wäre völlig ok ich will dir auch nicht rein reden - hin und wieder über den Tellerrand schauen, schadet aber sicher nicht.

 

[moep.at]

danke dir.

Schau ich mir auf alle Fälle an deswegen poste ich ja hier!

So wie es bis jetzt lief war ich eh nie zufrieden... will es "besser" machen... jetzt hab ich wenigstens die Motivation auch mal über den Tellerrand zu schauen als Angestellter... naja... eher weniger