Salut à tous et bienvenue à l'Unhandled Exceptions podcast, je suis Dan Clark et c'est
épisode numéro 13 et c'est une fredi-fri, mais non-fri-13, donc nous sommes tous bons.
Et aujourd'hui je suis jointé par mon ami Duchamp Prydashi et le principal thème de l'épisode est
tout à l'heure sur DevOps, donc un grand bienvenue à la chambre de Duchamp. Merci, merci, j'ai hâte de vous
être ici. Alors, vous pouvez donner et les listeners un petit overview de votre
background et ce que c'est que vous êtes en train de savoir. Donc, j'ai été un software
ingénieur, je dirais ingénieur parce que j'ai commencé à sauver le système de développeur,
puis j'ai commencé à faire beaucoup de travail de DevOps et maintenant je suis allé faire
plus de technologie de platform, mais mon travail de jour en jour, je pense que ça a changé beaucoup
parce que j'ai été en train de faire le software et je suis toujours en train de faire le software,
mais en train de faire le software, je veux dire que le software de faire de la technologie
peut être en relation à la plateforme et les teams de développement qui travaillent avec
leur software. Donc c'est un bon endroit pour être parce que vous avez les réponses et les
feedbacks de vos utilisateurs, pourquoi vous êtes en train de faire le bien et c'est un endroit
de privilège. Avant de faire ça, j'ai commencé à faire un travail avec Java et beaucoup
de netbeams, ITE et Eclipse, mais bientôt, je pense que à l'heure du master's degree,
j'ai commencé à enlever plus sur Docknet et C sharp et depuis que je n'ai pas juste
été avec Microsoft Technologies et je suis en train de travailler avec C sharp, Docknet et Azure, DevOps,
CICD automation. Donc, c'est ma travail.
Donc, on a fait des travail ensemble sur Sharp Life Science, qui est une compagnie qui a
travaillé sur le code de la technologie et on a fait des tests de la technologie et on a fait des tests





few people agreed that it is not a zero service and I think few said it should be as
though, which to me doesn't sound like an abbreviation. It sounds like a completely new name
of a product.
I think that's what they refer to internally Microsoft. And I think a lot of people just
say DevOps as well, which obviously is quite a loaded term, but I quite like Ados. Maybe it's
just because that's what we got used to using. But it works. So are you still living in the
land of Ados in your new role?
Not really. I think so you know how there is now a new push towards either Ados or GitHub
from Microsoft. So you should be choosing one of those if you want to work with Microsoft
CICD systems.
And the place I work, there is more interest and I see there is more value as well and
us moving towards GitHub.
But currently we are actually using Octopus and TeamCity. So TeamCity for all build, like CI
testing and all those business and then Octopus for our deployments.
And for deployments, we work mostly with Azure Cloud.
We do have other clouds like AWS and some Google resources as well, but that's minority,
mostly Azure and all the deployments we are using Terraform at the moment.
So that's essentially what we're doing.
So currently I am quite far from Ados.
I don't see myself going back.
I do miss it because I think compared to many other CI CD tools that I've used, Ados
is obviously more than CI CD.
But in that perspective, compared to say, cruise control, Jenkins and few others,
I think Zyotavovs is far mature.
It has way too many features, which are really useful features.
J'espère que GitHub mette ce standard.
Je voudrais bien revenir à GitHub versus Ados, parce que je suis très intéressé
en savoir si je devrais me changer de la vie pour GitHub, mais je pense que
nous devrions vraiment commencer à toucher sur ce que le terme DevOps veut dire.
Je pense que c'est toujours un point de technologie, comme on peut le automater.
Mais je sais que c'est vraiment beaucoup plus que ça.
Comment décidez-vous d'une sorte de DevOps qui est complètement nouvelle?
Pour DevOps, je pense que nous allons commencer un peu de l'histoire de ce que nous avons passé.
Historiquement, dans le software, nous avons été deux groupes de groupes
ou des groupes de personnes qui travaillent ensemble, qui ne travaillent pas ensemble.
C'est pourquoi DevOps a été créé.
C'était DevOps et DevOps, qui sont les développeurs et les opérations.
Donc le travail de développeurs a historiquement été de créer des nouvelles features
pour ajouter des features pour un product existant.
Mais le travail de la operation est d'assurer que ces features
soient délicates à l'application des clients,
comment on décide de créer un website, comment on va faire de l'application des clients.
Donc, en théorie, les développeurs ne veulent toujours changer,
parce qu'ils veulent changer, ils veulent ajouter de nouvelles features.
En même temps, les opérations préfèrent moins de changer,
parce que ça ne veut pas que les gens ne soient pas malade sur les choses qui sont en train de faire le mal.
Parce que c'est plus déterminant.
Et, pour le moment, historiquement, il y a eu un cas entre les préoccupations de les groupes
et il y a eu un cas entre eux.
C'est comme une wall hyperactrice, qui n'est pas assez de communication.
Donc le concept de DevOps a été dit,
nous devons mettre ce cas entre les deux et les ops.
Nous devons faire sure que les groupes de ces deux
travaillent ensemble, qu'ils comprennent plus, et qu'ils font plus de communication,
et qu'ils font plus de communication.
Donc c'est essentiellement la théorie derrière DevOps.
Je me souviens de la façon dont Microsoft définit les DevOps,
qui est, je pense que le point est,
c'est l'union des personnes, du processus et du product,
pour délivrer la valeur de votre client ou votre client.
Et ça fait du sens, parce que dans les DevOps,
c'est un set de pratiques.
C'est comme vous travaillez,
pour délivrer la valeur de votre client.
Donc pour cela, vous avez besoin d'un certain nombre de personnes.
Vous avez besoin d'une personne qui estOK pour apprendre la technologie,
et vous avez besoin d'un développeur,
mais vous aussi besoin d'understand les pratiques opérées.
Parce que sans comprendre comment vous faites de la manière
difficile pour la prochaine équipe,
vous n'aurez pas pu délivrer.
Et pour les opérations, vous avez besoin d'un certain nombre de personnes.
Je suis sûr que ce sera jamais 100% de la team de la fonction.
Que tout le monde croit que nous pouvons,
mais l'understand doit être là.
Et je pense que le bout de la fin est les outils et les produits
de ce que vous utilisez,
et comment vous le faites facilement,
comme nous avons discuté sur le DevOps,
ou des entreprises Gitter,
ou la team-city, ou tout autre.
Ce qui vous aide à automater,
à vous faire surement que vous faites votre test,
votre test de sécurité,
et que vous utilisez la communication gap
entre les deux DevOps.
C'est essentiellement ce que je comprends de DevOps.
C'est une excellente explication.
J'ai travaillé dans des places où il y a été
une séparation claire de la team de DevOps et de DevOps.
Et plus recentement,
je pense que je fais plus de cloud et de web,
beaucoup de la team en travaillant avec tous les développeurs,
tous les développeurs en s'envergant les mains
et le DevOps à côté des choses.
Mais dans ces entreprises, je ne vois pas que beaucoup de gens de DevOps.
Je me demande si c'est assez commun
ou si c'est encore un endroit.
Je suis sûr qu'il y a un endroit où les DevOps vont très bas,
et je pense que,
si vous avez parlé de sécurité,
de la point de vue de sécurité,
si les DevOps ont juste une base d'économie
de DevOps, et que c'est un peu...
Je vois des actions de GitHub,
des ADOS,
on peut juste faire ça à tous les uns.
On introduit beaucoup de risques de sécurité
par faire ça et ne pas avoir
ces experts, des gens opérationnels.
Je pense que...
Je suis encore prêvé de travailler
dans des teams de DevOps
et aussi, comme une team de DevOps,
je travaille avec des gens
qui sont des membres de la team opérationnelle.
Je vois un grand différence
entre l'understand et le connaissance
d'un développeur, même un développeur senior
pour l'architecture technique.
Ils comprennent des choses, mais quand il s'agit de pratiques,
on pense encore d'un développeur.
On veut délivrer le changement.
Mais souvent,
on l'a remarqué, c'est les gens opérationnels
qui se bloquent
ou qui se bloquent un peu.
En expliquant pourquoi ce ne devrait pas être fait.
Et beaucoup de fois, on a remarqué
que c'est la façon de réduire
le temps de la dévouement.
C'est pourquoi je pense que c'est important
de travailler avec un nombre de skills.
Évidemment, nous avons besoin de devs
pour délivrer les features.
Nous avons besoin d'opérations.
Et par rapport à la sécurité,
la société que je travaille avec
est très importante.
On ne peut pas être issue
entre les services financiers.
Si vous ne vous suivez pas des complérences
des PCI, des TSS,
en ce cas,
les membres d'opérations
qui ont travaillé en similar et en plus
ont compréhé les issues de sécurité.
Et il y a des choses comme
quand vous déploiez un fonction,
vous voulez un ordinateur AD.
Mais
notre équipe de sécurité
et notre équipe d'opérations
ne sont pas une équipe,
nous sommes tous une équipe de la plateforme.
Ils vont assurer
que ce n'est pas pourquoi nous arrêtons.
Le AD est un truc,
mais sur ce point, nous devons
assurer que les autres ressources
sont les mêmes que nous avons
pu accesser sur le feu,
l'IP, la liste,
ou les autres restrictions
que nous pouvons appliquer.
On va juste aller au-delà de la sécurité
et de ne pas avoir de loups pour les autres.
Et pour cela, nous avons besoin
d'un mix de plusieurs secteurs de sécurité.
C'est certain.
Nous pouvons parler
de l'infrastructure,
parce que vous avez mentionné le terraform
mais tout ce qui est de sécurité
si vous avez le sens de la santé
et que les gens avec différents secteurs
peuvent regarder et savoir
que c'est ce qui a été appliqué
plutôt que quelqu'un qui va
changer des conditions de sécurité
pour changer le port de l'Ajou.
Je pense que ça le fait
que le port de l'Ajou
soit un des plus grands bénéfices
pour la sécurité.
Je crois. Je pense que c'est très important
d'understand que
tout le port de l'Ajou
fait très facile.
Ce n'est probablement pas le moyen
de faire ça.
C'est très unpredictable.
Il y a des cas où les gens
ont changé les choses en prod.
Mais le problème est que le prochain
fois que vous déploiez,
le terraform ne sait pas
que vous avez changé le régime.
Il va le réciter à la fin
et puis vous êtes en square-run
pour le raison dont vous voulez le réciter
en premier place.
Je pense que
Automation, CICD, c'est ce qu'on doit faire
à la fin et en fin de la fin.
On a des choses différentes,
peut-être que nous devons changer
quelque chose.
Mais le moment est prêt, il doit être scripté.
Le terraform, l'arm template,
c'est le meilleur pour votre équipe.
C'est pourquoi vous devez le déployer
et ne changez pas de régime en prod.
Je n'ai pas de réciter
les choses de la manière dont je fais
les choses, mais si je fais
un nouveau projet, je ferai
le régime manuel.
Je ferai les choses
dans le développement.
Je trouve que
même au début,
quand je commence,
je ferai le code infrastructurien.
Je tend à avoir des projets
où je fais les mêmes.
Je peux copier et payer des codes
et appeler.
Ça ne devient pas
techniquement mal.
Et on a la consistance
du début.
Je pense que
le premier temps
que je déployais un cash
redis,
je serais peut-être
en train de le faire.
J'espérais être argumentant et
ridicule.
Mais après je vois
quoi c'est, jeDu
rai une deuxième Pod
je ne serai jamais pillage
un nouveau desen.
Autant, conducted flavored
anglophone
อง
tiris
au plume

pour
3
suis
paré
des bases des jours à jour, Pulumi pas si beaucoup.
On peut vous donner des théories sur Pulumi.
En théorie, tous de ces, Pulumi, Terraform, Arm,
même le nouveau BISEP, tous de ces
travaillent avec Rest API,
ils sont tous juste en train de tricter
les rest API de l'un ou l'autre.
Et le bon chose avec Arm, c'est que
c'est comme de la paix, c'est comme de la ressources que vous êtes
donc c'est la payload que vous vous soumettez
pour les rest API et c'est ce qui s'applique.
C'est bon d'avoir l'intérêt que vous êtes
presque en train de prendre les plus
précisions de la ressources de Microsoft,
ou de la documentation de Microsoft, vous vous avez
l'application de JSON.
La difficulté que j'ai, ou je pense que
beaucoup de teams aussi, et historiquement
ma campagne de campagne de campagne
a aussi l'air d'avoir, c'est difficile de
lire et de maintenir JSON.
C'est très bon pour la machine, mais pas pour un
tel type, c'est très facile de lire,
je n'aime pas les choses que vous avez modifiées
et vous avez regardé les modèles entre
les teams et tout ce genre de choses,
mais la difficulté ici est les files

Et les files de state, en tout cas,
dans un équipe où je travaille,
on déploie probablement 300
et 400 ressources,
toutes automatisées,
et à ce point, quand la state


file est correcte, ou se déploie,
c'est une majeure de la nuit pour nous,
parce que les deux choses peuvent arriver,
vous pouvez importer ces ressources,
donc vous pouvez importer les files de state
de majeure, et répliquer,
mais il y a des cas où les gens ne savent
qu'ils peuvent le faire et ils vont
le déployer de toute façon, à ce point,
il ne détruit pas les ressources, parce que
ça dit, ok, ma file de state est correcte,
cette ressource ne devrait pas être là,
donc je vais le remettre.
Donc nous avons des contrôles en place
pour faire surement que les gens ne savent pas
le faire, mais il y a encore des cas où
les gens peuvent le faire, donc c'est
une majeure de la nuit pour nous.
La seconde est la sécurité,
le problème que je pense que beaucoup
de nous avons avec Terraform, c'est que
il y a même des passwords en texte en texte
et des files de state, donc ça veut dire
que nous ne pouvons jamais utiliser,
bien, au moins, comme une
company de service financière, nous ne pouvons
pas utiliser Terraform Cloud,
en ce moment, qu'ils ne savent pas
leur business de encryption, jusqu'à
qu'ils puissent signer la salaire avec nous.
Donc pour cette raison, nous avons
impliqué notre propre infrastructure,
qui est en train de garder ça dans nos
contrôles de la seule, dans le site
de nos entreprises, comme votre subscription.
Mais cela signifie qu'il y a un extra
bouton sur la team de Terraform Engineering
pour faire surement que quand nous avons besoin
d'accès aux files de state, comment nous
le faisons et comment nous ne le faisons pas,
et plus souvent que pas, il y aura des teams
qui vont avoir besoin d'accès, parce qu'ils veulent
faire des nouvelles, ou qu'ils vont
augmenter Terraform, d'une certaine,
par exemple, donc c'est extra
pour les personnes.
Alors, comparé avec Pulumi,
j'aime l'idée de déployer des ressources
des sources, par exemple,
c'est un JavaScript ou un JavaScript type,
c'est une bonne idée, mais le concept
de state file est toujours là.
Donc je ne vois pas
un grand improvement
dans la théorie, parce que maintenant Terraform
introduit CDK, qui est, je pense,
c'est le kit de développement cloud,
qui est soutenu en JavaScript et
bientôt pour soutenir C sharp, aussi.
Si une des technologies
peut prendre le file de state ou
faire le travail avec des files de state,
ça pourrait faire une meilleure option.
Je réalise que
j'ai lu ça, je n'ai pas essayé de le faire,
mais Pulumi
fait des files de state dans un database
de base, un storage de base.
Donc ça pourrait être une meilleure option.
Si vous êtes au courant de
utiliser un file de state, une technologie
de développement.
Le autre qu'on investit en
bicep, c'est que
nous nous déploie beaucoup de bicep,
je pense que bicep est un bon candidat
à être utilisé, surtout quand ils ne
n'ont pas des files de state et vous pouvez
convertir, nous avons quelques de nos
déploiements en template armé
et on peut convertir
de la base de la base de la base
et déployer à l'assure.
Ça nous rend beaucoup plus facile,
mais c'est important
de comment on peut le faire.
Et je pense que la version 0.3 est
sortie, donc on pourrait essayer de la faire
avant de l'entraîner.
Je n'ai pas entendu de la cdk
qui a été introduite en Terraform
que vous avez mentionnée. Est-ce que ça va
travailler comme Terraform, parce que vous avez
mentionné de C-Sharp, sdk.
Est-ce que ça va travailler similaire
à Pulumi, où vous pouvez rééter
les codes?
Comme je le disais, la différence entre Terraform
et Pulumi est que Terraform
est un des des des désires de state.
Vous avez des files de YAML.
C'est ce que j'ai envie de mon environnement
de voir, où je n'ai pas utilisé Pulumi, mais
comme je l'ai compris, c'est très
programmatif, donc vous pouvez avoir
des statements, des lois et des choses.
Ça veut dire que la direction Terraform
va aller avec ce cdk?
C'est l'idée,
je ne sais pas comment le
management de la marketing a travaillé, peut-être
ils ont vu Pulumi cross et ils ont vu
qu'il y a un marché là-bas.
Mais avant de regarder le cdk,
vous pouvez mettre les codes
dans un très similaire manière
de ce que nous avons écrit en Pulumi.
Je n'ai pas essayé de faire
4, mais j'ai vu des exemples
de ces codes, donc je suis très sûr que
nous pouvons faire ça aussi.
Et en fin de la fin, je pense que
dans le monde, ça fait le même chose.
Je pense que le code
va toujours se couper sur la
Terraform core, et ça va
juste se couper
pour déployer les ressources.
Donc en théorie, nous devons
pouvoir faire ce que Pulumi
fait, mais c'est encore tout à fait.
Donc, la dernière fois que je l'ai checké, je pense que c'était
l'année dernière, en octobre,
quand ils ont montré le JavaScript,
et C-SHAF est encore là.
Donc je dois vérifier si C-SHAF est là ou non.
Oh, wow, je suis en train de
regarder, ils ont maintenant
la soutien pour C-SHAF.
Cdk pour Terraform 0.1.
Oh, wow, ils ont la soutien pour
Java, donc maintenant vous pouvez
en Write in Java, Dan.
Oh, non.
Ok, je suis pas le bon. C'est la juillet 2020,
donc je dois l'avoir entendu,
à partir de là.
Il y a TypeScript, Python, Java
et C-SHAF pour la Terraform CDK.
Je ne sais pas si ça existe, mais c'est
aussi.
Oui, donc ça se passe en juillet 2020
quand C-SHAF est soutenu.
C'est très bon.
Vous m'avez donné beaucoup plus de choses
pour le lire.
C'est bien de essayer ça,
parce que
à mon travail, et même au-delà de l'outil, je
utilise le DSL,
le langage hashikov.
C'est bien de essayer de C-SHAF et de
voir comment ça se prépare, et si ils
font votre vie facile ou pas.
Mais ça a l'air
très, très facile à utiliser.
Je pense que mon main bif
avec Terraform est de rester en train
de faire un plan de management state.
Je vous souhaite vraiment qu'ils puissent
venir avec la solution.
Je pense que ça va être
pour leur cachement, un problème
que si ils y arrivent,
vous pouvez avoir des issues de performance

Oui, possiblement.
Parce que le BICIP peut le faire, parce qu'ils
sont seulement utilisés par des templates armés
sous la route, donc peut-être que c'est
plus facile pour eux.
Et, selon Terraform, ils restent
des cloud multi-multi-clouds.
Ils ont toujours besoin de
leur file de state.
C'est un bon point que vous avez mentionné
avec Terraform et
Pulumi, vers un point de vue de
armes, où l'armée est juste
pour Azure, ou Azure Resources.
Si vous utilisez quelque chose comme Pulumi, vous
peut-être utiliser Cloudflare, ou
multiple Cloud providers.
Et vous pouvez utiliser le même
de la façon de faire l'infrastructure
pour déployer plus de pieces
de votre environnement.
C'est un point valide.
Mais en même temps, si vous êtes
une compagnie, vous pourriez
évoquer un multiple Cloud, ou vous
concentrez sur un Cloud.
Parce que je vois une debate sur les deux sites.
Et je pense que c'est le meilleur.
Mais, qu'est-ce que vous pensez ?
Mon opinion est,
c'est de prendre le point que vous savez le meilleur.
Je ne vois pas le bénéfice de
faire multi-cloud.
Mais, comme je l'ai dit
avant, je utilise Cloudflare
pour des websites.
Ce n'est pas nécessairement
juste multi-cloud. Vous avez des
différents trucs. Vous voulez
déployer des ressources Azure,
quelque chose de Cloudflare,
une email provider, comme Sengrid,
ou d'autres supports Azure, mais
ce n'est pas juste
que vous utilisez Azure,
ou AWS, ou Google Cloud.
Il y a d'autres choses que Terraform
soutient aussi. Et je pense que
avoir cette consistance
de la façon dont vous vous dites
votre file de déployement est assez bien.
Oui, oui.
J'ai vu cette debate sur plusieurs podcasts
aussi,
comme les vidéos
que nous avons vu sur Cloud, Google
vs. Azure, ou tout autre.
Et il y a des sensibles arguments sur les deux sites.
Mais une des choses que je pense,
c'est que si vous n'êtes pas
pas fiers d'un lock-in,
vous seriez utilisés plus
d'un Cloud, et vous allez explorer
plus de ressources de Cloud,
de la ressources et des features de Cloud.
Mais si vous êtes plus
spreadant à plusieurs Clouds,
ça signifie que vous devez
avoir plus de gens qui savent
que ce sont des Clouds. Donc vous
pouvez juste augmenter la cost
par spreadant à des Clouds.
Pour votre cas, oui, ça ne fait pas le sens.
Si vous avez un déployement
qui fait quelque chose de Cloudflare
et en même temps, vous faites quelque chose d'assurant,
je ne sais pas si ce Cloudflare
fait de la plus grande, si ça fait de la plus grande,
c'est un win-win.
Oui, ça fait de la plus grande.
Azure est juste un des
des providers dans Terraform, mais
il y a beaucoup d'autres aussi.
C'est bien. Mais avec le multi-Cloud,
je vous remercie. Si vous vous
tenterez de faire des différents,
vous allez peut-être
aller avec le plus bas commun
de la feature.
Mais ils sont tous
en compétition avec eux-mêmes.
Donc, vous avez les functions Azure,
vous avez AWS Lambda. Ils sont tous
regardés à ce que les autres
font et en essayant de créer un similar.
Parce que c'est les compétitifs, non?
Je ne pense pas que les plateformes
de Clouds soient de la plus grande
pour l'année prochaine.
Je ne suis personnellement
pas fiers de être lois
dans un de ces plateformes.
Oui, je pense que
si vous êtes une grande company,
pas une grande organisation,
comme NHS,
peut-être que vous avez des raisons
de aller avec des clouds et de différents projets.
Mais la plupart des compétitifs
ne vont probablement pas avoir besoin de ça,
si ils ne le voient pas
en plus d'avoir des professeurs
de différents clouds
et de travailler ensemble.
Mais oui, je pense que
Cloud Lock-in ne le voie pas
comme un problème.
Je ne le remercie pas.
Je crois que c'est un point
avec DevOps
qui est le concept
de test.
Nous avons aussi des tests unis
et des tests de integration.
Comment cela peut s'améliorer
les pipelines DevOps?
D'abord,
les tests de test de test de test de test de integration
vont être automatisés.
Je pense que dans le monde UI,
nous avons encore des tests manuels.
Mais par la perspective de code,
ce sera automatisé
des tests MATHED
ou un test de integration,
et si nous options
WAX et GitHub,
nous avons
des tests beaux.
Front de parallel important de Des address
Nations Géné�О.

ideally, you would also be looking at the code coverage of your code when you're deploying your test.
But at the same time, it's my personal opinion, I find code coverage not to be a good indicator of how healthy your code is.
It's more about feature coverage, that's what I feel, but I don't know if there is a way to actually say your code, all your features, except that you have lots of codes around anything that you've changed.
In that case, yes, it goes back to TDD, doing the right test beforehand and then writing your code and then deploying using a pipeline.
About testing, the other bit I wanted to add here is testing of infrastructure's code is also becoming more and more important.
It has always been important, but because people or teams did not write lots of infrastructure's code, it probably wasn't that much important 2, 3 years ago.
Now with Terraform ARM templates, it's vital because I could be changing a part of the Terraform code without understanding what it's going to do or what it's going to affect.
So obviously, the Go TerraTest, the Go framework, it's a good way to test.
So we, in our team, we currently are looking at Go TerraTest as well as thinking of writing our own N-unit-based testing framework for Terraform because in the and all this TerraTest is doing, as far as I've investigated, is that it will do the Terraform plan and check in the plan, the state file.
Is it the expected output there or not?
And then you can deploy that plan and then check on Azure if you have the right set of resources or not.
So we could do the same testing using N-unit if we just deploy Terraform as a separate process and then check that JSON file has the right values.
So that's one thing, but in the same time about security testing, there is TFSEC.
So TFSEC is an open source static analysis tool.
So it doesn't really test it, but it does analyze your Terraform code to find out, say, are you deploying web apps without HTTPS, for example, or any kind of security loop holes that you might have in your Terraform code, it will flag it straight away.
And it's really easy to use because you can easily do it in a Docker.
So in a Docker, I do actually have a post on this that you can do TFSEC scan inside a Docker image of your whole Terraform code base.
And in the end, you'll just get a XML file, which can be N-unit XML.
C'est super intéressant.
J'ai fait beaucoup de tests en integration et UI, et j'ai essayé de mettre ces tests dans mes pipelines, mais je n'ai pas encore considéré mes codes de code.
C'est très cool, surtout avec le stuff de sécurité.
Donc on peut définitivement inclure les liens dans les show notes pour que tous ces choses soient recueillis.
Mais où est-ce que vous pourriez dire que le meilleur endroit est d'aller apprendre tout ce type de DevOps, Terraform et Azure pipelines?
Le meilleur endroit serait Microsoft Docs, parce que c'est pour ça que vous allez avoir le plus de choses.
Mais en même temps, l'entraînement est en train de faire.
Et je pense que seulement en faisant, vous le apprendrez plus vite et vous comprendrez mieux.
Et la principale motivation que je trouve à apprendre de nouvelles technologies est d'examiser un examen certifié sur le examen.
Et avec Microsoft Exams, et je pense que si vous allez pour Microsoft Ignite Event et même Docker Docs, vous pouvez gagner des vouchers sur le Microsoft Exam.
Donc c'est une bonne motivation pour aller et prendre un examen.
Et la bonne chose sur l'exam, c'est que vous allez, évidemment, quand vous faites l'exam, vous allez apprendre sur le site de l'on.
Vous allez aller voir sur le YouTube de Microsoft.
Et quelques autres places.
En même temps, pendant votre apprendre pour votre propre examen, je suis sûr que vous allez trouver beaucoup plus d'informations,
dont vous trouverez une meilleure surface de l'exam.
Et je réalise que quelques de ces examens ont été pris.
Ce qui m'a fait mieux pour moi, en tant que développeur, même quand je suis juste en train de apprendre sur le DevOps,
parce que vous pouvez voir où ces principes viennent de, qui sont appliqués sur le DevOps.
Ou en même temps, je faisais l'exam sur la sécurité, par exemple.
Et là, vous pouvez voir pourquoi vous voulez utiliser le Azure AD,
en en créant vos propres détails pour pouvoir utiliser l'ID et la passée.
Il y a quelques choses que vous allez apprendre, ou non, beaucoup de choses que vous allez apprendre,
qui vous appréciez les examens plus en plus.
Et en temps, je pense que ça va vous faire mieux développer, mieux en général.
Même si vous êtes le manager, vous pouvez vous faire mieux le manager,
parce que vous comprendrez la situation plus avec Azure et Cloud et la technologie.
Donc, oui, les examens, je vous recommande, c'est vraiment le meilleur moyen de apprendre maintenant.
Je vous rappelle, quand nous avons travaillé sur la vie,
nous avons eu beaucoup de discussions sur les examens Azure,
et vous étiez en train de faire votre première chose, je pense, à la fois.
Et le matin, à la place, vous me direz que je l'avais étudiant pour l'heure dernière,
et en faisant toutes les examens pratiques.
Et puis, à mon avis, je pense que je vais aller voir et faire ces examens aussi.
Et c'est là où j'ai été, à l'honneur.
Je fais beaucoup de reading et de la lecture,
et de la podcast, et de la faire de la date.
Mais, comme vous l'avez mentionné, il y a beaucoup de choses,
je pense que, en faisant ces examens,
vous ne savez pas pas, sans faire les examens,
parce que les podcasts et les blogposts,
ils parlent toujours de la Chine,
pas les choses fondamentales qui sont importants de apprendre.
Oui, c'est une très bonne chose,
que si vous allez faire l'exemple,
parce que vous vous l'aurez appris beaucoup,
et le problème avec beaucoup de examens,
c'est que je trouve que les questions d'exemple sont parfois utilisées.
Vous allez probablement être en répondant à quelque chose,
qui n'est pas normal dans les news.
Ça me coiffe parfois.
J'ai évoqué avec mesuré,
et l'exemple de l'exemple de Microsoft.
J'ai évoqué avec eux aussi.
Mais, je pense qu'ils sont toujours deux mois en-delà de ce qu'il y a,
mais en même temps, si vous voulez passer l'exemple,
vous allez encore en répondre dans l'exemple.
Mais en même temps, c'est bien,
parce que les examens Microsoft,
je réalise, n'est pas trop facile.
Donc, si vous avez juste avancé et avez pris un exemple simple,
si vous vous l'avez passé, vous êtes très heureux,
parce qu'ils font ça difficile pour passer l'exemple.
Commençons par comment ils ont installé l'exemple avec le proctorat,
la personne qui vous a mis un oeil sur vous,
ou peut-être plus que l'un d'entre vous,
quand vous avez fait l'exemple.
En mon cas, j'ai pris l'exemple de la maison,
donc il y a un proctorat, un proctorat online.
Donc, vous devez avoir l'habitude de cet environnement,
et de vous faire confiance,
de vous dire que quelqu'un me l'a regardé
dans la caméra tout le temps,
et que vous ne pouvez pas être, je ne sais pas,
en marchant ou en regardant de l'écran.
Si vous pensez, pensez sans regarder le oeil,
par exemple, et tout ça.
Et en ce moment,
comprendre la technologie, parce que ces questions
ne sont pas très straight forward,
comme, qu'est-ce que l'a été fait par Ato?
Il y aura beaucoup plus,
comme un cas de company,
et de vous dire,
comment vous le réunissez?
Je vous aime bien ces questions,
mais elles testent votre compétition,
pas le fait de ne pas savoir un terme.
Donc, en général,
oui, je pense que c'est une expérience de l'exemple.
Et pour commencer par l'exemple,
vous pourrez peut-être aller au processus de la course de la course,
qui est un site avec
beaucoup de la façon de la formation de l'expérience.
Donc, si vous finissez le module,
vous allez avoir des points et des choses.
Et c'est un bon endroit pour commencer,
parce que vous avez des environments
de la salle de la course,
pour essayer de faire des choses différentes.
Et vous pouvez juste aller mentir et ne pas
faire de l'effet de n'importe qui.
Et en même temps, parce que vous le faites,
vous avez un extra-learn sur ce que vous avez besoin de savoir.
Oui, Microsoft Learn
est tellement utile.
Et ce n'est pas seulement pour les examens,
c'est juste que si vous voulez apprendre,
il y a beaucoup de paths et modules,
c'est juste un endroit
pour apprendre.
Donc, je vais, encore une fois,
inclure un lien pour ce que vous avez fait dans les notes de la show.
Donc,
nous allons faire des tips de la course.
Je dois faire deux tips de la course.
L'un est pour développer en général.
Si vous êtes un développeur
et vous voulez improvement de vos skills,
ou peut-être que vous êtes en train de faire des choses,
ça sera assez utile pour vous.
Donc, il y a un site qui s'appelle
DailyCodingProblem.com.
Et ce qu'il faut faire, c'est que
chaque jour ils vous envoient un nouveau challenge de programme
ou une question de programme.
Et ils disent que ce sont des questions
des questions réelles,
des questions de Google, Microsoft, Amazon
et beaucoup d'autres entreprises.
Ça ressemble à ça, je n'ai pas checké ça,
mais les questions sont vraiment belles.
Donc, ça sera comme test de votre understanding
de programme, de votre understanding
des notes de la course,
la complexité de vos algorithmes.
Et c'est un truc,
juste pour répondre à la question, mais c'est aussi important
que vous répondrez avec la meilleure
complexité possible,
comme en least
la plus vite possible
de l'exécution du algorithme.
Donc, pour cette raison, je recommande
de passer au DailyCodingProblem.com
et si vous avez des temps à free,
vous pouvez essayer de faire des problèmes très intéressants.
On va voir ça maintenant.
Un problème de code
des jours.
Les questions sont vraiment belles,
ils ont deux arrêts et ils doivent faire quelque chose avec eux.
Et comment faire avec BigoM plus 1
ou BigoM
sans aller à BigoM2.
Mais ils ne se réveillent pas de la solution.
Et je pense que vous devez être prêts
pour trouver la solution.
Je suis maintenant sur le site web
et je vais
signer.
Dépêchez-vous.
Comme un suivi, je pense que vous êtes en train
de mettre un GitHub,
où chaque fois que je prends un problème,
je vais essayer de le répondre
dans le GitHub.
Et j'espère que ça peut
augmenter la code,
que BigoM est vraiment mal et que je le mettrais.
Oh, bien.
Oui, ça va être bien.
Mon deuxième devtif est plus
au zéro centric.
Si vous êtes un app de fonction et un developer de web,
il y a un bouton sur votre panneau
qui dit « Diagnose et Solve Problems ».
C'est votre ami.
Ça vous aide à assurer beaucoup de problèmes.
Si vous êtes débargé de votre app,
vous devez définir
que vous devez aller au point de diagnosis et de sols.
Et voir que la configuration
pourrait être faite. Vous pouvez vous pointer
à la même histoire.
Ou peut-être que vous n'avez pas un contact
de la histoire.
Vous êtes restricatés à certaines IPs
qui ne devriez pas être restricatés.
Et, en plus,
l'autre app est votre app Insights Live Metrics.
Donc, ces deux ont sauvé
mes jours, si pas
les semaines, quand j'ai essayé
de débargir mes appes et web.
Les app Insights Live Metrics sont amusant.
Et nous pouvons faire un tout épisode
en fait, on va bien, mais
c'est très, très bien.
Si vous avez fait deux dev-tips,
je vais faire deux dev-tips aussi.
Mon premier est un livre.
Il y a deux livres, exact.
L'une est appelée « Le projet Phoenix »
et l'autre est appelée « Le projet Unicom ».
Je ne sais pas si vous l'avez lu.
Non, je n'ai pas.
J'ai toujours eu les PDFs avec moi.
J'ai toujours pas lu.
Je vous recommande.
Les deux sont des livres fictionnels.
Mais il y a une histoire
tout en dévops et une compagnie
« Parts Unlimited » qui commence
avec une compagnie très inefficient
avec beaucoup de problèmes à travers le bord.
C'est une histoire de comment ils ont voulu
dévops et complètement dévopser
comment leur compagnie s'est travaillé.
Une des livres est d'un perspective IT
et l'autre est d'un perspective DEV.
Mais c'est la même histoire que les deux points différents de vous.
Je vous recommande de
vous entendre et de vous entendre
tous les livres, car ils sont
très relativement liés.
Je vais vous inclure un lien dans les notes de la show.
Mon deuxième DEV.
C'est des codes snippets.
C'est un peu off-topique
que le theme de la devops.
Je vous recommande de
avoir un endroit pour tous vos codes snippets
et codes notes.
Je l'ai utilisé « Notion »
qui est coincident de la dernière episode
« Matneal »
« Notion » est assez
comme un wiki sur les steroids.
Mais la décision de « Tooling » est en train de vous
de vous, votre ID
probablement a de support snippet.
Je préfère
mon snippet d'être au-delà de l'ID
car je n'ai pas de snippet pour les choses
que je n'aurais pas fait dans mon ID.
Par exemple, les snippets commandes,
step-by-step breakdowns, cheatsheets, notes,
tout ça.
Et si vous avez code quelque chose de nouveau,
c'est bien d'avoir un step-back
et
de vous arrêter de vous demander
si il y a quelque chose de générique
sur ce code que vous voulez faire
qui pourrait aller dans votre library snippet
ou notes.
Qu'est-ce que vous voulez faire de ce truc
dans le futur ? Parce que je trouve que ça me
a un grand nombre de temps. Et c'est
sur le surprise de la question de
comment les développeurs
répétent les mêmes tasks
sur les projets.
Et souvent ils se réinventent
dans le rouleau à chaque fois, ou ils se réagissent
sur le même problème.
Ce sont mes conseils.
Avant de vous rappeler,
vous avez d'autres choses que vous voulez mentionner ?
Je veux rapidement mentionner
une compagnie que je travaille pour New Day
des cartes de New Day en Londres. Nous sommes
currently hiring. Si vous êtes en train de
faire un travail, vérifiez notre site
newday.co.uk
et vous êtes touchés.
Et si vous vous êtes à
travailler à l'arrivée du Chant, je vous recommande
de vous rappeler. Je vous remercie
quand nous travaillions ensemble, on a
toujours été au gym à la fin de la nuit.
Je suis un grand
personne à travailler avec. Je vous jure
ces jours.
Merci. Je vous jure aussi
des musiques de gym
qui sont vraiment belles.
Nous serons en retard.
Je dois trouver un gym.
Je pense que je suis remotely,
c'est un terrain de travail
entre nous.
Je suis en Kent
Asheville.
C'est super.
Vous m'avez mis plus loin.
On va faire le centre de Londres
chaque semaine.
Peut-être que le Covid
s'en est clair.
Très bien.
Merci beaucoup
pour les joueurs. C'était super
de vous avoir regardé.
Merci beaucoup.
Merci à tous d'avoir regardé.
Je vous remercie
d'avoir regardé.
Merci beaucoup.











Merci d'avoir regardé.
Merci d'avoir regardé.
Merci d'avoir regardé.
Merci d'avoir regardé.
Merci d'avoir regardé.
Merci d'avoir regardé.


Merci d'avoir regardé.
Merci d'avoir regardé.
Merci d'avoir regardé.


Merci d'avoir regardé.
Merci d'avoir regardé.