Instal·lar i configurar Microsoft Dev Home en equips d'empresa

Si gestioneu un parc d'ordinadors amb Windows 11 a la vostra empresa, segurament ja haureu vist aparèixer Inici Dev com una de les novetats orientades a desenvolupadors. Microsoft ho planteja com un panell de control centralitzat per a programació, integració amb GitHub i automatització d'entorns, però també es creua amb altres solucions corporatives com ara Microsoft Dev Box i Windows Dev Center, pensades per a equips de desenvolupament grans i molt estandarditzats.

En entorns corporatius no n'hi ha prou de saber que una eina existeix: necessites entendre per què serveix exactament Dev Home, com encaixa amb l'estratègia de TI de la teva organització i quin impacte té en seguretat i administració. Al llarg d'aquesta guia veureu detalladament què és Dev Home, com instal·lar-lo i configurar-lo en equips d'empresa, com s'integra amb GitHub, Azure DevOps i Dev Drive, i com es relaciona amb Microsoft Dev Box i el mode desenvolupador de Windows 11 perquè puguis prendre decisions amb criteri.

Què és Microsoft Dev Home i en què es diferencia d'altres solucions

Microsoft Dev Home és una aplicació per a Windows 11 dissenyada com a centre de control per a desenvolupadors. Es tracta d'un dashboard personalitzable des del qual podeu monitoritzar el rendiment de l'equip, gestionar projectes, integrar comptes de GitHub o Azure DevOps i automatitzar la creació d'entorns de desenvolupament mitjançant WinGet i catàlegs de configuracions.

Tot i que a simple vista alguns usuaris ho comparen amb PowerJoys, en realitat juguen en lligues diferents: PowerToys és un conjunt d'utilitats per personalitzar i ampliar Windows amb petites funcions, mentre que Dev Home se centra en facilitar la feina diària de programació i l'administració d'entorns en màquines de desenvolupament.

En un context empresarial, Dev Home es pot fer servir tant en equips físics com en màquines virtuals, però el seu màxim sentit apareix quan es combina amb pràctiques modernes com IaC (infraestructura com a codi), WinGet i repositoris centralitzats. D'aquesta manera, el departament de TI pot definir plantilles d'entorn i els desenvolupadors poden aixecar-les amb uns clics.

Convé diferenciar també Dev Home del mode desenvolupador de Windows. Moltes instal·lacions de Windows 10 i Windows 11 mostren opcions de “Inici per a desenvolupadors” o “Mode de desenvolupador”, que habiliten característiques extra com la instal·lació d'aplicacions fora de Microsoft Store, l'ús d'eines de diagnòstic avançades o la integració amb subsistemes com WSA. Dev Home, en canvi, és una interfície unificada i orientada al flux de treball del programador, no simplement un interruptor de permisos.

En equips on els usuaris no són desenvolupadors, el més habitual és mantenir desactivada la manera de desenvolupador per reforçar la seguretat, mentre que Dev Home ni tan sols tindria sentit instal·lar-lo. En estacions de treball de desenvolupament, però, pot ser una peça més de la caixa d'eines corporativa, sempre que se'n controli el desplegament i la configuració.

Funcions clau de Dev Home per a equips d'empresa

Per valorar si t'interessa desplegar Dev Home a la teva organització, és útil repassar les funcions més importants que ofereix a nivell professional. Més enllà del màrqueting, hi ha tres grans blocs de capacitats que resulten especialment rellevants a l'empresa: configuració d'entorns, dashboard amb ginys i la integració profunda amb GitHub i Azure DevOps.

Configuració ràpida dentorns de desenvolupament amb WinGet

Un dels punts forts de Dev Home és que permet automatitzar la instal·lació d'aplicacions, paquets i repositoris necessaris per a un entorn de desenvolupament estàndard, estirant WinGet com a motor d'instal·lació. Des de la pròpia interfície gràfica pots crear o consumir configuracions que inclouen:

• Aplicacions d'escriptori (IDE com Visual Studio o VS Code, navegadors, eines de testing, etc.).
• Paquets i llibreries de desenvolupament (SDK, runtimes, CLI de diferents proveïdors).
• Repositoris de codi que es clonen automàticament en preparar la màquina.

En una empresa on entren nous desenvolupadors o es canvien freqüentment de projectes, aquesta funcionalitat pot estalviar moltes hores d'instal·lació manual i reduir errors humans. TI pot definir plantilles base per equip o per producte i Dev Home s'encarrega d'executar l'script necessari mitjançant WinGet i altres eines d'automatització admeses.

En recolzar-se en configuracions declaratives, també resulta més senzill mantenir l'homogeneïtat entre estacions de treball, una cosa clau quan després es vol reproduir incidències o garantir que tots els membres de l'equip disposen de les mateixes versions d'eines.

Dashboard i ginys personalitzables

Dev Home inclou un tauler principal completament modular on pots afegir ginys orientats tant al rendiment de l'equip com a l'estat dels teus projectes. Per a un entorn corporatiu això resulta útil perquè cada perfil (backend, frontend, DevOps, QA) pot ajustar la vista al que realment necessita.

Entre els widgets disponibles destaquen els de monitorització de maquinari, que mostren mètriques com lús de CPU, GPU, memòria RAM o xarxa en temps real. Això permet detectar colls de botella durant compilacions pesades, proves de càrrega o execució de contenidors sense haver dobrir eines addicionals.

També pots integrar widgets específics per GitHub i Azure DevOps, amb informació sobre issues obertes, pull requests pendents, estat de builds o tasques assignades. L'objectiu és que el desenvolupador tingui una mena de “centre de comandament” on vegi d'una ullada com va la feina i com es comporta el seu equip de desenvolupament.

Encara que pugui sonar una cosa cosmètica, en projectes grans aquesta centralització evita estar saltant constantment entre navegador, IDE, portal d'Azure i eines de seguiment, amb el consegüent estalvi de temps i menys distraccions en el dia a dia.

Integració amb GitHub, GitHub Copilot i Azure DevOps

Una altra peça interessant per a empresa és la integració nativa de Dev Home amb GitHub i Azure DevOps. En vincular el compte corporatiu de GitHub, els desenvolupadors poden:

• Connectar ràpidament els seus repositoris de treball sense configurar-ho tot a mà.
• Veure des de Dev Home l'estat de issues, pull requests i notificacions rellevants.
• Accedir a funcions de GitHub des de Windows de manera més directa.

A més, Microsoft està impulsant que GitHub Copilot s'integri en pràcticament totes les eines de desenvolupament habituals a Windows: terminal, Visual Studio Code i altres editors. Dev Home no és el motor de Copilot, però sí el lloc on orquestrar bona part de l'ecosistema, facilitant als equips d'empresa adoptar l'assistent d'IA dins un entorn controlat.

En organitzacions que usen Azure DevOps, Dev Home permet vincular projectes i pipelins per mostrar-los al dashboard i llançar accions ràpides, cosa que encaixa especialment bé en cultures DevOps on es vol escurçar el cicle entre codi, integració contínua i desplegament.

Dev Drive: emmagatzematge optimitzat per a desenvolupament

Dev Home incorpora suport per Dev Drive, un tipus de volum d'emmagatzematge pensat específicament per allotjar codi font, repositoris i eines de desenvolupament. El seu propòsit és millorar el rendiment en operacions d'E/S intensives, com ara compilacions grans o anàlisi de codi, i alhora reforçar certs aspectes de seguretat.

Per als equips dempresa, això significa que es pot separar clarament l'espai utilitzat per al desenvolupament de la resta de dades de l'usuari, cosa que dóna joc a l'hora d'aplicar polítiques diferents (per exemple, diferents nivells d'exclusions de l'antivirus, còpia de seguretat més freqüent de repos, etc.).

La promesa de Microsoft amb Dev Drive és que es puguin crear, depurar i processar fitxers de codi de forma més ràpida, reduint temps de compilació i millorant l'experiència general del desenvolupador. A escenaris on cada minut de compilació compta, no és un avantatge menor.

A més, en ser un volum amb característiques específiques, permet aplicar protocols de seguretat i control d'accés ajustats al context de desenvolupament, una cosa especialment sensible quan es manegen repositoris amb propietat intel·lectual crítica per a l'empresa.

Instal·lar i actualitzar Dev Home en equips corporatius

La forma més directa d'instal·lar Dev Home a Windows 11 és a través de microsoft Store. L'aplicació es troba en fase Preview en molts entorns, per la qual cosa convé tenir clar que encara pot mostrar errors o comportaments inestables, alguna cosa a tenir en compte abans dun desplegament massiu en producció.

En equips individuals només cal obrir la Store, buscar “Dev Home” i iniciar la instal·lació com qualsevol altra aplicació UWP. En un context corporatiu, el més habitual és que el departament de TI gestioni aquesta distribució mitjançant polítiques, catàlegs interns o eines de gestió com Intune, decidint quins grups d'usuaris poden instal·lar o utilitzar Dev Home.

Per mantenir l'aplicació al dia, Microsoft també ofereix la possibilitat d'actualitzar-la via Windows Terminal usant WinGet. La comanda típica seria:

winget upgrade Microsoft.DevHome

Aquesta ordre comprova si hi ha una versió més recent disponible i, si escau, la instal·la automàticament. D'aquesta manera pots integrar l'actualització de Dev Home en scripts de manteniment o tasques automatitzades, cosa molt útil quan gestiones desenes o centenars d'estacions de treball de desenvolupament.

Convé recordar que Dev Home, en algunes compilacions de Windows 11, va arribar a instal·lar-se automàticament com a aplicació preinstal·lada. Aquest moviment va generar que part dels usuaris la percebessin com a bloatware, mentre altres la van rebre amb entusiasme per la seva utilitat en entorns de desenvolupament. Aquest “amor-odi” ha influït en les decisions posteriors de Microsoft sobre el seu futur dins del sistema.

Ús de Dev Home a Windows 11 Home i mode desenvolupador

A molts fòrums de suport han aparegut dubtes d'usuaris de Windows 11 Home que veuen “Dev Home” o el mode de desenvolupador i no saben si desactivar-ho. Des del punt de vista corporatiu, és important distingir què implica cada cosa per a seguretat i suport.

L'anomenat “Dev Home” en alguns diàlegs de configuració en realitat es refereix al mode de desenvolupador del sistema, una característica present tant a Windows 10 com a Windows 11. En activar-la es desbloquegen funcionalitats com:

• Instal·lació en proves d'aplicacions que no provenen de Microsoft Store.
• Ús de ferramentes de diagnòstic avançades i paquets de desenvolupament addicionals.
• Accés simplificat a tecnologies com WSA oa certs kits de rendiment.

Per a un usuari que no és desenvolupador, aquestes característiques no només aporten poc, sinó que a més obren la porta a riscos de seguretat i estabilitat si s'instal·len aplicacions sense control o es relaxen certes polítiques del sistema. Per això, en un entorn d'empresa, el més normal és mantenir desactivada aquesta manera excepte en equips que formin explícitament part de l'àrea de desenvolupament.

Desactivar el mode de desenvolupador pot provocar que algunes aplicacions deixin de poder instal·lar-se o executar-se, de manera que abans de canviar l'ajust convé verificar que ningú no depèn d'aquesta via per desplegar programari. En estacions usades únicament per a tasques ofimàtiques, comptabilitat, atenció al client o altres perfils no tècnics, és recomanable deixar-lo apagat.

Quan sorgeixen problemes connectats a aquest tipus d'opcions avançades (per exemple, assistents o wizards que fallen en entorns de desenvolupament molt personalitzats), moltes vegades la causa surt de l'abast del suport estàndard i convé escalar el cas a canals més especialitzats, com ara els fòrums de Microsoft Learn, on enginyers i experts aprofundeixen en escenaris complexos.

Microsoft Dev Box: equips de desenvolupament al núvol per a organitzacions

A més de Dev Home, Microsoft ha llançat en paral·lel Microsoft Dev Box, una solució basada en Azure per oferir estacions de treball de desenvolupament completes al núvol. Mentre Dev Home s'instal·la en màquines locals, Dev Box es recolza en màquines virtuals gestionades de forma centralitzada i pensades com a “caixes de desenvolupament” d'autoservei per als equips.

Una Dev Box és, bàsicament, una VM preparada com a lloc diari d'un desenvolupador, amb el sistema operatiu, eines i recursos necessaris per a un projecte concret. Des de la perspectiva de TI, Dev Box es configura en dues fases: primer els enginyers de plataforma preparen els recursos a Azure Portal i, després, els desenvolupadors creen i administren les seves pròpies caixes a través del portal per a desenvolupadors.

A l'arrencada del servei es crea un centre de desenvolupament, que actua com a punt central per gestionar projectes, definir mides i imatges de les Dev Box disponibles i configurar opcions de xarxa que permetin a les màquines accedir de manera segura als recursos interns de l'organització.

Requisits previs per desplegar Dev Box a l'empresa

Abans de poder oferir Dev Box als teus equips de desenvolupament necessites complir una sèrie de requisits tècnics i de llicenciament:

• Compte d'Azure amb subscripció activa. Si no teniu subscripció, heu de crear un compte (per exemple, començant amb un gratuït).
• Permisos adequats. Es requereixen rols de Propietari o Col·laborador sobre la subscripció o el grup de recursos on es crearan els recursos de Dev Box.
• Llicències d'usuari que incloguin Windows 11 Enterprise o Windows 10 Enterprise, Microsoft Intune i Microsoft Entra ID P1. Aquestes llicències vénen en paquets com Microsoft 365 E3/E5, A3/A5, Empresa Premium o Advantage per a Educació.
• Administració de dispositius amb Microsoft Intune, que serà la base per gestionar les estacions de treball virtuals.
• Identitat gestionada amb Microsoft Entra ID, utilitzada per a autenticació i control d'accés.
• Proveïdor de recursos Microsoft.DevCenter registrat a la subscripció d'Azure, necessari per utilitzar Dev Box.

Sense aquesta base, no podreu avançar en la configuració del servei. En moltes empreses això implica coordinar els equips d'infraestructura, seguretat i desenvolupament per alinear les llicències, polítiques i permisos adequats abans d'arrencar.

Creació d'un centre de desenvolupament a Azure

El primer pas operatiu per configurar Dev Box és crear un centre de desenvolupament a Azure Portal. Des d´aquí s´orquesten projectes, imatges, xarxes i polítiques comunes. El procés general inclou:

• Accedir a Azure Portal i cercar el recurs “Centres de desenvolupament”.
• Iniciar la creació seleccionant la subscripció i un grup de recursos (existent o nou).
• Assignar un nom al centre i triar la regió d'Azure on residiran els recursos.
• Decidir si s'adjunta un catàleg d'inici ràpid de definicions d'entorn, que inclou configuracions predefinides que podeu adoptar o personalitzar.

A la pestanya de configuració pots activar o ajustar diversos comportaments per defecte:

• permetre catàlegs a nivell de projecte, perquè cada equip adjunti el seu propi catàleg a més del centre de desenvolupament.
• habilitar la xarxa allotjada per Microsoft per a projectes, simplificant enormement ladministració de xarxes per a les Dev Box si no necessites una topologia molt personalitzada.
• Configurar la instal·lació automàtica del agent d'Azure Monitor a totes les caixes de desenvolupament, de manera que s'enviïn mètriques i logs a Azure Monitor sense passos addicionals.

Un cop revisada la configuració, es llança la creació i es monitoritza el progrés des del panell de notificacions. Quan acaba, pots anar al recurs i comprovar que el centre de desenvolupament apareix correctament registrat i llest per associar projectes.

Projectes i grups d'equips de desenvolupament (Dev Box pools)

Dins un centre de desenvolupament, els projectes són la unitat on es gestiona la configuració a nivell d'equip. Cada projecte agrupa la configuració d'accés, límits i catàlegs que s'aplicaran als desenvolupadors que hi treballin.

En crear un projecte a Azure Portal, defineixes aspectes com:

• La subscripció i el grup de recursos on s'allotjarà.
• El centre de desenvolupament associat, les configuracions del qual heretarà el projecte.
• Un nom i una breu descripció per identificar-lo clarament.

A la pestanya de configuració de la caixa de desenvolupament decideixes si permets personalitzacions dusuari en crear les seves pròpies Dev Box i si estableixes límits al nombre de caixes que cada desenvolupador pot aixecar. Això resulta clau per controlar costos, tal com detalla la documentació de Microsoft al seu tutorial de límits de Dev Box.

Els projectes poden tenir adjunts catàlegs que defineixin entorns d'implementació i imatges. En habilitar les opcions corresponents, Dev Box sincronitza automàticament aquestes definicions perquè estiguin disponibles en crear grups d'equips de desenvolupament.

Un grup d'equips de desenvolupament (Dev Box pool) és una col·lecció de caixes de desenvolupament que comparteixen la mateixa configuració d'imatge, regió, xarxa i opcions d'administració. Cada projecte necessita com a mínim un grup perquè els usuaris puguin desplegar els seus Dev Box.

En crear un grup tries:

• Un nom visible per als desenvolupadors quan seleccioneu quin tipus de caixa voleu crear.
• La imatge o definició de Dev Box que servirà com a base (imatge de Marketplace, imatge personalitzada, definició d'imatge YAML o definició de Dev Box heretada).
• La mida del procés (tipus de màquina virtual) i l'emmagatzematge assignat a cada caixa.
• La regió i la forma de connexió de xarxa, normalment usant xarxes allotjades per Microsoft per simplificar.
• Si s'aplicarà el benefici híbrid d'Azure de llicències Windows per optimitzar costos.

A la pestanya d'administració del grup també es configuren:

• Els rols dels usuaris dins de la Dev Box (administrador local o usuari estàndard).
• L'habilitació del inici de sessió únic (SSO) amb credencials organitzatives.
• La possibilitat de obrir Dev Box sense escriptori complet directament des del Visual Studio Code (connexió sense capçalera).
• Controls de costos com la detenció automàtica segons horaris, hibernació en desconnectar o després de períodes de gràcia quan ningú es connecta.

Quan creeu el grup, Azure executa comprovacions d'estat sobre la imatge i la xarxa per validar que compleixen els criteris necessaris. Només llavors queda disponible perquè els desenvolupadors aixequin les caixes al portal corresponent.

Tipus d'imatge i definicions usades a Dev Box

Un punt crític en la gestió de Dev Box és triar el tipus d'imatge amb què s'aprovisionaran les estacions de treball de desenvolupament. Microsoft ofereix quatre opcions principals, cadascuna amb el cas d'ús ideal:

• Definició d'imatge: fitxers YAML que parteixen d'una imatge base i apliquen personalitzacions específiques (instal·lació de programari, configuració de sistema, ajustaments d'equip). Són ideals per entorns estandarditzats per equip, on es vulgui automatitzar completament com queda la màquina.
• Imatge personalitzada: imatges de l'organització emmagatzemades a Azure Compute Gallery. Permeten seleccionar de forma independent la mida de procés i l'emmagatzematge, i resulten útils per a configuracions molt específiques de l'organització.
• Imatge de Marketplace: imatges preconfigurades llistes per al seu ús (per exemple, Windows 11 Enterprise o imatges amb Visual Studio). Són adequades quan es volen estàndards força genèrics amb eines de desenvolupament comuns, mantenint flexibilitat en la mida de la VM i el disc.
• Definició d'equip de desenvolupament: opció heretada que combina en un sol paquet imatge base, mida fixa i configuració d'emmagatzematge. Es recomana sobretot per compatibilitat amb configuracions antigues, encara que Microsoft anima a migrar cap a imatges personalitzades o de Marketplace.

Azure Compute Gallery facilita compartir imatges personalitzades a tota l'organització, mentre que el catàleg de Marketplace cobreix la majoria de escenaris estàndard de desenvolupament a Windows. Triar bé entre aquestes opcions impacta directament en la productivitat i en la facilitat amb què TI pot actualitzar o posar pegats als entorns.

Control d'accés i delegació a administradors de projecte

Perquè els usuaris puguin crear Dev Box des d'un projecte concret, és obligatori concedir-los accés mitjançant assignacions de rol a Azure. El rol clau és “Usuari de Dev Box de DevCenter”, que permet a cada desenvolupador crear, gestionar i eliminar únicament les seves pròpies caixes de desenvolupament.

La bona pràctica és assignar aquest rol a nivell de projecte, escollint si s'aplica a usuaris individuals, grups de seguretat o entitats de servei. D'aquesta manera, qualsevol persona amb aquest rol veurà els projectes i grups associats i podrà desplegar Dev Box adequades a la feina des del portal per a desenvolupadors.

A més, Microsoft ofereix el rol “Administrador de projectes de DevCenter", que permet delegar lʻadministració diària de projectes en membres de lʻequip sense donar-los permisos globals. Aquests administradors poden gestionar grups de Dev Box, establir límits, configurar horaris dʻapagat i programacions dʻescalat, però no poden afegir usuaris al projecte; aquesta part continua sent responsabilitat d'administradors amb més abast.

Amb aquesta combinació de rols es pot construir un model de governança equilibrat: TI marca els grans paràmetres (llicències, xarxa, imatges mestres) i els administradors de projecte ajusten detalls operatius per al vostre equip sense poder trencar l'estructura global.

El futur de Dev Home a Windows 11 i el seu impacte en empresa

En versions recents de Windows 11 s'ha avançat que Dev Home deixarà d'incloure's com a aplicació preinstal·lada al sistema. Microsoft ha decidit retirar-la de futures compilacions, cosa que ha generat reaccions trobades entre els usuaris.

D'una banda, n'hi ha que consideren que l'impacte serà mínim perquè Dev Home tenia un ús relativament limitat a la base d'usuaris general i molts la catalogaven com a bloatware quan va aparèixer de sèrie al sistema. D'altra banda, bona part de la comunitat de desenvolupament estava satisfeta amb la seva evolució, especialment després de la darrera actualització important rebuda.

Alguns professionals critiquen que Microsoft tendeix a abandonar productes que no “exploten” en popularitat immediatament, en lloc de donar-los marge i continuar iterant fins a consolidar-los. En el cas de Dev Home, això es percep com una oportunitat perduda per oferir un panell de control robust integrat nadivament a Windows 11.

Tot i això, que deixi d'estar preinstal·lada no vol dir que no es pugui continuar utilitzant on aporti valor. És probable que Dev Home continuï disponible a la Microsoft Store oa través d'altres canals mentre Microsoft decideixi mantenir-la viva, cosa que permet als equips de desenvolupament seguir recorrent-hi si els encaixa en el seu flux de treball.

A organitzacions on Dev Home ja s'ha integrat com a part del dia a dia, la retirada del sistema base implica simplement revisar la forma de distribució (per exemple, passar a desplegar-la explícitament via Intune o scripts) i prestar atenció a futurs anuncis de Microsoft sobre el full de ruta. Mentrestant, la combinació de Dev Box, eines d'Azure, GitHub i configuracions de WinGet continua cobrint el gruix de les necessitats d'un entorn de desenvolupament empresarial modern.

Amb tot això, es dibuixa un panorama en què Dev Home és una peça útil però no imprescindible dins de l'ecosistema de desenvolupament a Windows 11: per a equips d'empresa que busquen centralitzar la configuració d'entorns, aprofitar Dev Drive i tenir un panell únic amb GitHub i Azure DevOps, segueix sent una eina molt interessant; per a altres perfils menys tècnics o escenaris on ja s'utilitza Dev Box com a estàndard principal, és probable que el seu paper quedi més en segon pla, deixant el protagonisme a les solucions al núvol ia la gestió centralitzada d'imatges i polítiques.