[45k-50k] [Madrid / Remote] Startup busca Backend Developers

.

#37 Cuenta mas. ¿Que eres capaz de hacer desde 0? CI/CD from scratch? Montado todo en un entorno AWS con todas sus posibilidades (lambdas, elastic containers, etc...?)
¿Y porque usar Jenkins en AWS?

#68 Jenkins y cloud se usa mucho cuando tienes entornos híbridos onpremise/cloud y de esta forma controlas toda la infraestructura de CI/CD

Así lo tengo yo montado, mientras que tenemos parte en cloud, con lambdas para alguna cosa, la mayoría de ec2 las integramos en nuestro entorno CI que tenemos en una serie de servidores onpremise

#73 si te quieres quedar atado a AWS y gitHub si, con codePipelines te basta.

Al final se trata de usar lo que mas sentido tenga y más convenga a tus necesidades y entorno. Yo, en mi empresa, por la variedad de nuestra infraestuctura y versatilidad que te da Jenkins no nos planteamos ni por asomo usar otra cosa. Y nos va de puto lujo con él.

#75 Si. Bueno, lo despliego como servicio en Kubernetes pero si, puedes desplegarlo en un solo server y definir luego esclavos. Lo que pasa es que en mi caso los esclavos son pods de Kubernetes que se levantan, hacen el trabajo que tengan que hacer, y se tiran. No tenemos servidores esclavos levantados de forma permanente. Es una solución muy limpia y elegante.

Luego puedes definirle los pipelines que necesites de CI/CD. Yo lo tengo configurado para que cuando alguien hace push a un repo Gitlab le lance automáticamente la construcción y el análisis de código, el cual visualizamos en un sonar también desplegado en Kubernetes. Si todo va bien, Jenkins despliega la aplicación de forma automática en los entornos que definamos.

En otros casos llegamos solo al CI y el deployment lo hacemos mediante Jenkins también, pero bajo demanda o programado ciertos días a la semana, lo que necesite el proyecto, vamos.

La creación de la infrastuctura en la nube la tenemos definida como codigo mediante ansible y se lanza mediante Jenkins también.

#71 básicamente lo mismo que castocillo dice. En mi caso, mi empresa tiene un montón de maquinas físicas por el tipo de negocio al que se dedica, por lo que aunque estamos migrando a la nube, las maquinas siempre que se puede se reaprovechan.

Los repos (en mi caso, Gitlab y Svn) detectan un commit y comienzan el ciclo de CI (build, test y analisis). El ciclo de CD tambien esta automatizado en Jenkins pero se lanza a mano por tenerlo todo mas controlado. Y para la gestion de aprovisionamiento uso Ansible tanto en las maquinas fisicas como en las cloud.

#77bLaKnI:

Entonces el modulo de Jenkins se levanta solamente cuando un developer hace por ejemplo un commit,

Esto no es asi, siempre debe haber una instancia de Jenkins funcionando, en este caso el master, si no seria imposible que se enterase de que ha habido un trigger.

#77bLaKnI:

contemplando el diseño del protocolo de CI que hayas establecido en K8s

No, Jenkins gestiona el ciclo de CI/CD, K8s orquesta los recursos de los que Jenkins dispone y los dimensiona dependiendo de la necesidad del momento, si necesita mas instancias las crea, y cuando dejen de ser necesarias las elimina.

Estoy recibiendo muchos privados en los que me decís que la oferta os interesa pero que no tenéis experiencia con Ruby. ¡Ningún problema! Buscamos gente capaz de hacer buen software.

¿Qué entendemos por buen software? Grosso modo, que respete los principios SOLID y esté cubierto por tests.

Tampoco vamos a tirar a nadie por no tener experiencia implementando DDD, aunque sí que es un requisito para estar en la parte alta de la banda salarial.

Mañana o el lunes edito el post con toda la info que he ido poniendo en los hilos y añado también cómo es el proceso. Desde que aplicas hasta que te hacemos una oferta hay unas 6 entrevistas:

• Telefónica (Con alguien de RRHH)
• Team Lead (Tech Lead + Uno de nosotros random)
• Code Review (Tech Lead + El mismo que te hizo la otra)
• Peer Interview (2 Miembros del equipo random)
• Values (Con el VP de Payroll)
• Founder (Con alguno de los 3 fundadores, suele ser con Arseniy (CTO) o Roman(CPO))

Esta quedando un thread delicioso. Thanks.

Yo por mi parte, he sido (y soy en corazón) developer, desde que tengo memoria...
El tiempo y los años, me han llevado a la presente situación como CTO (sector financiero siempre, y empresa grande). El tema es que se me presenta una posibilidad nueva: hacer de CTO, pero en una startup que lo tiene todo por definir tecnológicamente (sector financiero también)...
Como CTO, me he encargado de las transformaciones digitales de allí donde he estado. Pero estas, han sido transformaciones de infraestructuras y migración de entornos, así como luego cambiando a rol de CIO, redefinición de procesos y modelo de negocio. Pero no hablamos de empresas de desarrollo ni programación. Con lo que el concepto CI/CD + DevOps tal como lo entendemos, no existe ni ha existido.
El "problema", es que en una startup como la que tengo en el horizonte, la función como CTO, esta por lo que veo, muy altamente dedicada a ello (CI/CD + DevOps puro). Y tengo que ponerme las pilas.
El tema, es que migraríamos todo el stack tecnológico presente (usuarios, active directory, fileservers, correo... etc. Lo que conforma la empresa como tal) a un nuevo entorno, y mentalmente, hubiera tirado por la vía clara: proveedor que acompañe bien, y hacer un proyecto full-VPC. Como hasta el presente.
Pero no puedo dejar de lado todo el entorno de desarrollo, y no vale en levantarles instancias de servidores en Windows 2016, y dejarselas con permisos administradores para que las alteren al gusto...
Así que tengo que mezclarlo TODO.
Al ser startup pequeña, como CTO, haría un poco de todo veo... Pero quizas sería interesante el proponer de buscar un perfil DevOps específico, con el que hacer tandem.
Lo que pasa es que no soy capaz de ver la dierencia o línia separatoria entre un CTO y un DevOps en una startup primeriza con un planteamiento de resoruceing-as-a-service según perfilado de codigo, como lo que comentábais ahora con AWS CloudFormation o Terraform. Esto ultimo, se carga literalmente la figura del CTO... o no, si este ultimo se encarga solamente de la infraestructura de la empresa, y la parte de infra que sostiene la línia de trabajo/developping, se plantea con budgets variables dinámicos, y se deja en manos de un head-developer con perfil alto DevOps...

¿que me decís?