Wie ich festgestellt habe, vermeiden viele Entwickler eine automatische oder manuelle Aktualisierung, weil sie befürchten, dass sie Änderungen an ihrer Maschine vornehmen könnten, die sie nicht verstehen, und die Software, die sie entwickeln, könnte aus bestimmten Gründen fehlschlagen Ich weiß es nicht.
strategie A.) VERLASSEN SIE DAS SYSTEM WIE ES IST, SO LANGE WIE MÖGLICH.
Ich persönlich bevorzuge es, mein System so "aktuell" wie möglich zu halten (OS und App), weil ich generell weniger Schwierigkeiten habe, so zu arbeiten.
Strategie B.) IMMER UP TO DATE
Welche Art von Entwickler bist du? Und warum?
B. Bestimmt.
Wenn Sie für eine Plattform mit unsicheren Update-Stammbäumen (z. B. The Real World) entwickeln, dann sind virtuelle Maschinen eine wichtige Waffe, aber es zahlt sich aus, bei der Veröffentlichung so aktuell wie möglich zu sein.
Es ist so viel einfacher, Ihren Benutzern zu sagen, "führen Sie einfach das Update aus", als zu versuchen, zu erraten, welche Patch-Historie das Problem verursacht (oder zumindest ausschließen kann).
Wenn Sie für eine rein interne Zielgruppe arbeiten, haben Sie wirklich nur eine Frage:
Nein.
Deshalb hat Gott virtuelle Maschinen erfunden.
Eine Art Bummer, wenn Sie ein OS X Programmierer sind, wegen des hardwarebasierten Kopierschutzes im Betriebssystem (Sie müssen auf Apple gesegnete Hardware laufen).
Halten Sie das Betriebssystem so aktuell wie möglich, vorzugsweise mit einem sys-Admin-Test Patches, bevor sie an den Rest des Unternehmens freigegeben werden.
Wenden Sie dev environment service packs relativ schnell an, überprüfen Sie jedoch zuerst eine VM, damit Sie sehen können, ob der Build noch funktioniert, und geben Sie diese Build dann QA für Rauchtests vor dem Upgrade der Dev-Maschinen.
Ändern Sie die Entwicklungsumgebung (und / oder die Plattform, z. B. Upgrade von Java 5 auf Java 6), wenn Sie einen echten Vorteil sehen, aber als explizite Aufgabe mit budgetierter Zeit zulassen. Idealerweise sollten Sie die Projektlaufzeit einkalkulieren, um die Entwickler auf den neuesten Stand zu bringen, damit sie das Beste daraus machen können. Mach das nicht in der Nähe einer Veröffentlichung.
Es kommt selten vor, dass die Zielmaschine für die Software, die Sie schreiben, dieselbe ist wie Ihre Entwicklungsmaschine. Daher macht es wenig Sinn, die Maschine nicht zu aktualisieren und sie alle statisch zu halten.
Nun, die Zielmaschine ... das ist eine andere Geschichte. Da möchte ich keine Änderungen, solange sie nicht unbedingt notwendig sind.
Ein gutes Beispiel dafür ist neulich bei meiner Arbeit passiert. Das IT-Team führte ein Update auf unseren Entwicklungsserver ein, das zunächst harmlos schien. Die Maschine hatte einen unbeaufsichtigten Login, der rund um die Uhr angemeldet sein musste. Das Update für Windows (ich müsste die KB herausziehen) meldet diesen Benutzertyp automatisch ab. Die Anwendungen, die wir auf dem Server ausführen, benötigen Logins, um ausgeführt zu werden (ja, ich weiß, aber das ist eine andere Geschichte). Plötzlich fingen unsere Systeme an, drunter und drüber zu gehen, und es kam zu Beschwerden, dass einige der verwendeten Softwaresysteme nicht funktionierten.
Wir haben das Problem ausfindig gemacht und den Admin-Benutzer wieder eingeloggt, aber erst nach drei Abmeldungen, die von Windows verursacht wurden, merkten wir wirklich, was vor sich ging. Glücklicherweise wurde nicht viel Schaden angerichtet, aber es bedeutete, dass einige Leute Überstunden machen mussten.
Updates sollten vor der Einführung überprüft werden, welche Auswirkungen sie auf Ihr Betriebssystem haben, und selbst dann sollten sie getestet werden.
B, aus Sicherheitsgründen.
Wie sehr Sie sich jedoch auch darum kümmern sollten, dass das Brechen von Dingen in Ihrer App sehr von der Art der Entwicklung abhängt, die Sie gerade machen. Der übliche Fall ist fast wie ein Cross-Compile für ein anderes Ziel, da kaum User-Maschinen wie Dev-Maschinen konfiguriert sind.
Wenn es sich um eine Webanwendung handelt, ist Ihre "Plattform" der / die Browser und was immer Sie auf der Serverseite verwenden. Für mich ist das Ruby, Rails und Plugins sowie Apache / MySQL usw. Client-Seite habe ich keine Kontrolle über. Server-Seite, ich möchte mindestens Sicherheits-Patches anwenden (beiseite: Plädoyer für Server-Entwickler, bitte Sicherheits-Patches in einem anderen Zyklus zu Funktionalität Änderungen freigeben!). . Aber Betriebssystemupdates haben normalerweise wenig Einfluss auf den Dev-Server-Stack, den ich verwende, und in jedem Fall verwendet meine Implementierungsumgebung ein anderes Betriebssystem (ich entwickle unter OSX und Ubuntu und deploy unter Debian und Solaris).
Wenn es sich um eine Desktopanwendung handelt, hängt es davon ab, wie eng Sie mit Ihrer Plattform integriert sind und ob Sie die Kontrolle über sie in der Zielumgebung haben. Da ich generell Java verwende, sehe ich, dass die Plattform nicht das Betriebssystem ist, obwohl es auf verschiedenen Betriebssystem-Varianten und Java-Versionen getestet werden muss. Wenn ein Patch auf dem Betriebssystem Java bricht, dann ist das ein separates Problem.
Wenn Sie sehr eng mit dem Betriebssystem verbunden sind, dann sind Updates Abhängigkeiten sehr schwierig zu testen und ist fast unmöglich ohne einige starke Nutzung von virtuellen Maschinen sowie Snapshots etc. Auch wenn Sie so zerbrechlich sind in Bezug auf Betriebssystem ändert sich Ihr Die App wird wahrscheinlich fehlschlagen, wenn Ihr Zielcomputer eine andere Softwarelast oder eine andere Konfiguration hat - wieder einmal sehr schwierig zu testen.
Führen Sie eine Aktualisierung durch, aber nicht während eines kritischen Zeitraums im Entwicklungszyklus. Verwenden Sie eine OS-Distribution, von der bekannt ist, dass sie so stabil wie möglich ist, und dass sie bekanntlich konservativ ist, wie oft Updates veröffentlicht werden.
Erzwingen Sie Ihren Entwicklern, ihren Code zu testen, wann immer sie einchecken möchten. Stellen Sie sicher, dass alle Tests bestanden haben, bevor sie ein Upgrade durchführen. Dies stellt sicher, dass sie eine Vorstellung davon haben, was bricht.
Es gibt eine Reihe von Dingen (ich schreibe aus Linux / Unix-Erfahrung, aber die Dinge sollten auch für andere Betriebssysteme gelten):
Ich bin mir bewusst, dass Unix-ähnliche Systeme eine größere Tradition haben, unabhängig zu sein als Windows-Systeme. Das ändert nichts an der technischen Solidität der OS-Annahme-Unabhängigkeit. Daher rate ich dazu, das Update möglichst bald zu aktualisieren, nachdem ein neues Update verfügbar ist (normalerweise nicht am ersten Tag), aber um sicherzustellen, dass es leicht zurückgerollt werden kann, wenn die Dinge wirklich kaputt gehen. Wenn das Projekt abbricht, werden die meisten Entwickler zurückgesetzt, wobei ein kleines Team daran arbeitet, es zu reparieren.
Da ist das alte Sprichwort. "Niemals ein laufendes System ändern". Ich denke, die Horrorgeschichten über miserable Updates sind Legion. Ich kann nur aus meiner Erfahrung sagen. Wenn Sie Software auf "gut aufgehängten" Komponenten basieren, ist die Wahrscheinlichkeit, sie zu brechen, viel geringer als bei schnellen Änderungen. Ein paar Beispiele: Unsere IDE basiert auf der Win API und läuft seit Windows 3.1 (wo sie entwickelt wurde) fast unverändert, wir haben über die Jahre ein paar nette Städte hinzugefügt, also wette ich, dass das Paket mindestens Windows 2000 benötigt. Aber ich kann Ihnen versichern, dass es viele OS-Updates von XP über Windwos NT, Windows 2000, Windows 2003, Windows XP, Windows 2003-64 und das "oh-so-glänzende" Vista überlebt.
Andererseits konnte ich mit dem gtk-basierten Port auf Linux nicht mithalten. Die API-Änderungen sind extrem. Das ist es, was ich am meisten an den Open-Source-Befürwortern hasse. Sie sind gezwungen, Ihre Arbeit immer wieder neu zu machen, nur um aktuell zu bleiben.
Ein weiteres Beispiel, das mich mindestens eine gute Woche Arbeit gekostet hat, ist das Update einer sehr kleinen Rails-Applikation von Version 1.1.6 auf 2.2. (und das in nur zwei Jahren). Ich befürchtete, dass es am schlimmsten wäre, aber war etwas positiv überrascht.
Grüße
Tags und Links windows macos linux maintenance