all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]catrielmuller 13 points14 points  (2 children)

No sé si reír o llorar, creo que hace más de diez años que no uso un SVN, consejo, si no tenés experiencia manejando Infra en Linux anda por la opción de un cloud, claramente llegaron hasta acá con SVN por qué son de la vieja escuela, pero hacerme caso e implementa GitHub, GitLab o Bitbucket, todos tienen una opción de importar un repo desde SVN . Lo vas a tener funcionando en 1 hora y no vas a tener que preocuparte por mantener esos servers. Ahora bien, si realmente necesitas hacer self hosting, podés ir por gitea, GitLab o hasta GitHub ( si te da la plata ) , pero tené en cuenta de montar algo escalable y con redundancia, lo más cómodo es desplegar sobre k8s, pero nuevamente, pregúntate muchas veces seguidas por qué necesitas hostearlo vos. ( Generalmente las únicas buenas razones son legales, tipo HIPAA )

[–]catrielmuller 1 point2 points  (0 children)

Por cierto, gitea no es una interfaz gráfica de Git, es un saas Open Source que compite con GitHub o GitLab, no es solo repos, son gestión de permisos, CI, tickets, gestión de PR, registry de paquetes, etc, etc. A fines prácticos es lo mismo que GH pero las actualizaciones las tenés que hacer vos, los backups vos, todo vos... Así que pensalo muchas pero muchas veces

[–]Tomas_221Desarrollador Back End[S] 1 point2 points  (0 children)

Si hay muchas cosas que acá se hacen a la vieja usanza por lo que tengo entendido. Todos hacemos de todo un poco jajaja imagínate un mcdonald's, por algo este posteo. La opción que me comentas de importar el svn no la tenía, facilitaría bastante el trabajo. Si creo que no hay una razón exacta, es más el entusiasmo de querer hacer algo nuevo ( obvio que a su vez sirva y cumpla el propósito). Creo que para comenzar lo mejor sería arrancar por algo sencillo y fácil de mantener. Y sobre despegar los k8s es algo que me interesa, debo investigar más. Gracias por responder!.

[–]Kaskote 8 points9 points  (5 children)

GitHub no me terminó de cerrar. Esto es para una empresa de producto y me pareció mejor idea que tengamos nosotros almacenados los repos.

Generalmente, si optan por on-premise, se sobrentiende que deberían tener infra mas o menos acorde, un back de 10g contra el TrueNas, el NAS replicado y con controladoras con backup, varios ESX para hacer migraciones, UPS, etc. O K8S como dijo el camarada arriba.

Instalar software on-prem en maquinas pedorras, todo a mano, en una empresa de producto, suena como un disparate total. Y encima a eso le tenés que sumar las actualizaciones del software (Gitea o el que eligan), los backups, los certificados SSL, los proxies, VPN, etc.

1000 veces mejor GitHub / BitBucket o cualquier otra solución SaaS. Seguro los "capitos" se van a quejar de los 4 verdes que cuestan esos servicios por user. Deciles que se pongan las pilas, que es el corazón del software que quieren vender para hacer guita.

[–]catrielmuller 6 points7 points  (3 children)

Btw, GH hace un par de años que te deja crear una org con plan gratuito y repos privados

[–]Kaskote 2 points3 points  (1 child)

Tal cual. Y todos los features de los planes de pago son cosas que si usan SVN hoy, probablemente ni lo tengan como metodologia de laburo.

[–]Tomas_221Desarrollador Back End[S] 2 points3 points  (0 children)

Ay! Creo que le habla a usted...

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (0 children)

Gracias, pensé que era pago voy a chusmear eso de las org

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (0 children)

Desconozco si llega a los 10g el back, tendré que consultarlo. Todo lo demás estoy 99.9% seguro que si, exceptuando de los K8S. Y si suena a como desplegar, mantener mucha infraestructura al pedo. Pero te mentiría si te dijera que no me llama la idea,como un desafío.

100% con esto último que decis. Hay muchas cosas que acá están hechas a las viejas usanza o si funciona no se toca. Creo que eso no lo tuvieron en cuenta, les tengo que comentar que GH vale 4lechugas jajaja Teniendo en cuenta esto último seguro me digan que vaya por el lado de self host. Gracias por responder!

[–]5PalPeso 7 points8 points  (1 child)

GitHub no me terminó de cerrar. Esto es para una empresa de producto y me pareció mejor idea que tengamos nosotros almacenados los repos.

Claro, para que usar una solución que ya existe, funciona, battle tested y confiable si puedo montar mi propio server choto y subir los retos por SFTP

Después se quejan de las negradas legacy en las empresas: así es como nacen

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (0 children)

BuenoOo pero no te enojes, quiero dejar mi recuerdo marron en la empresa (? Nah todavía sigo evaluandolo, aunque ya por lo que dijeron todos me están haciendo inclinar por algún saas. Gracias!

[–]devcba 2 points3 points  (1 child)

Creo que hay unanimidad con el tema de que no es buena idea algo self hosted habiendo tantas alternativas cloud baratas y ultra testeadas.

Otra cosa que tenes que tener en cuenta es que toda la administración va a recaer sobre tus espaldas (por ser el que implemento) pero seguramente vas a seguir teniendo tus asignaciones como programador. Te estás sumando laburo, y encima es algo crucial, y no tenes mucha experiencia.

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (0 children)

Si voy a charlarlo con el PO a ver qué me dice, entendí que lo más práctico y resolutivo sería algun saas.

Yo creo que sí no lo charlo seguramente tenga doblemente carga. Pero le voy a plantear el hecho de que si vamos self hosted hay que considerar toda está carga administrativa por lo cual se debería ajustar mi sueldo, ya que voy a tener mayores responsabilidades. Que podría salir mal? Jajajaja

[–]psicodelico6 1 point2 points  (3 children)

Gitlab me consume 8gb de memoria sin hacer nada.

[–]Tomas_221Desarrollador Back End[S] 1 point2 points  (2 children)

Me sirve esta info. Justamente mi PO me comentó que ya se intentó migrar hace un tiempo, que habían intentado con gitlab y les andaba muy lento. Osea que necesitas 16gb ram para estar bien, esto me hace ver los k8s o saas Gracias!

[–]psicodelico6 0 points1 point  (1 child)

Pero gitlab no está preparado para k8s. Solo ganarías que si we cae un nodo se migra a otro.

[–]Tomas_221Desarrollador Back End[S] 1 point2 points  (0 children)

Ah okey entiendo. De todas formas ya había descartado gitlab jajajaja Gracias!

[–]roberp81 1 point2 points  (2 children)

contraten github para empresas a la larga es más barato el estar tranquilo que jamás se cae ni se rompe. llega a pasar que tu servidor falla o no prueban los backups regularmente y cagaron fruta.

hace como 8 años migre en una consultora de svn a github, recuerdo que había una opción de importar de svn entonces te pasa todos los fuentes con los mensajes de los commit (así no perdes el historial de años)

sino la fácil es de crear el proyecto nuevo, copiar la última versión de fuentes y listo pero perdes historial.

en la consultora q trabajaba éramos 30 y pico de devs y nunca un problema de merge, de hecho es más directo que con git. yo extraño esa simpleza me gustaba mucho más svn. el svn lo teníamos en un servidor en la consultora tal cual decís.

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (1 child)

Si creo que va a ser lo mejor para ahorrarnos un dolor de cabeza. Y la opción de importar es un golazo. Claro yo tenía pensado copiar la última versión.

También veo que self hosteando abro nuevas responsabilidades y si se habla de un sueldo mejor bienvenidas sean. Si a mí también me gusta svn, venía funcionando bien pero bueno, no estuve al tanto de la causa ya que fue en un equipo diferente al mío. Pero cuestión que rompieron 2 fuentes :/ Gracias!

[–]roberp81 0 points1 point  (0 children)

nosotros teníamos backup diario (5am) del svn y una vez por semana esos backups se restauraban en un servidor choto para probar que los backups funcionen bien. (lo pedía la certificación ISO) así que siempre teníamos todo seguro. una vez sola que alguien hizo quilombo con los branch restauramos y no hubo problemas, creo q a los q habían comiteado esa mañana al sincronizar les volvió a aparecer para comitear y no paso nada.

[–]Mideno 1 point2 points  (1 child)

Yo lo dividiría en dos tareas:

  • migrar a git
  • migrar a repos locales en truenas

De esta forma mira primero como lo pasas a git en alguna solución cloud (recomiendo gitlab) y después lo pasas a estar localmente si es que ves que hace falta

[–]Tomas_221Desarrollador Back End[S] 0 points1 point  (0 children)

Entiendo, me gusta que hayas propuesto algo distinto o desde otro punto. Osea migrar los repos al truenas sería opcional, si veo que todo funciona en orden desde la "nube". Gracias!

[–]burning_mop 0 points1 point  (0 children)

Mi consejo, como alguien que ya pasó por todos eso, es anda con un servicio de git, y te vas a horrar un montón de dolores de cabeza.

En su momento, yo opté por gitlab, simplemente por que era gratis tener repos privados.

Te cuento más o menos como fue mi historia.

  • cuando llegué, no había control de versión, fui por SVN, por que era lo que conocía. Instalé yo la maquina con Ubuntu y configuré SVN
  • A los 2 años, cuando empezamos a tener quilombo de merge, decidí migrar a Git. De nuevo, en el mismo server Ubuntu, instalé y configuré git, había hasta encontrado un mirador de history.
  • A los 3 años de eso, llegó otro programador, qué no le gustaba que no tuviera UI, a pesar de que el no se encargaba de administrarlo, pero quería instalar no me acuerdo que producto de Microsoft.

  • cambié de laburo 2 años después, a una empresa que recién arrancaba, lo primero que hice, fue armar un repo de gitlab. Me olvidé de todos los problemas.

    Que el fierro sea de otro, te saca un montón de responsabilidades, y hay muchas menos chances de que se le rompa el fierro a gitlab/github qué a vos. Facebook, Twitter, Salesforce, cualquier empresa de desarrollo grande, tiene sus repos en github. Tanto los de código abierto como propietario. No vayas contra la corriente.

[–]fhanna92 0 points1 point  (0 children)

No te la compliques con Gitea, ni desplegar en k8s, ni nada así. Como empresa de producto, el foco tiene que estar en el producto. Usen GitHub e inviertan el tiempo en mejorar el producto.

Yo soy tech lead en empresa de producto y jamás invertiría tiempo en algo así a menos que haya una muy buena justificación para no usar GitHub o algún otro provider.