Sou um grande fã do Azure DevOps desde os primeiros dias, quando ainda era chamado Visual Studio Online. Eu o uso para fins profissionais e pessoais,
e recomendo aos meus clientes de consultoria.
No entanto, não importa o quanto eu elogie esta plataforma, muitas vezes é difícil convencer os desenvolvedores de Node ou Java de que o Azure DevOps se sairá bem com seus projetos, nada pior do que para o .NET. Independentemente do número de demonstrações e apresentações que refutam os preconceitos, em qualquer grupo há pessoas que acreditam firmemente que o ADO não é adequado para eles, porque é uma "ferramenta da Microsoft".
Deixando de lado o debate filosófico, posso explicar a maior parte da resistência pela falta de compreensão de como o Azure DevOps evoluiu de seu antecessor Team Foundation Services (TFS) e me tornei a melhor caixa de ferramentas da classe capaz de oferecer suporte a projetos de qualquer tamanho "em qualquer idioma e qualquer outro plataforma ". A questão é: como posso provar conclusivamente isso de uma vez por todas?
Eu brinquei com essa idéia um pouco, e então me dei conta. A prova precisa ser feita sem a criação de outra demonstração de CI / CD para os microsserviços SpringBoot implantados no Kubernetes na AWS - ela precisa ser feita com uma abordagem mais excêntrica.
E agora algo completamente diferente
E se pararmos de focar em linguagens e plataformas modernas e avançarmos 30 anos atrás para ver se ferramentas modernas e o ADO podem ser usados para desenvolver, criar, dividir em módulos e implementar um programa criado para uma plataforma de computador de 8 bits?
Como no caso de outras demos para o ADO que eu criei no passado, eu queria mostrar um produto completamente acabado - desde a edição do código, verificação e assim por diante, até o ambiente ao vivo no qual você pode assistir as alterações.
Em teoria, tudo isso parecia bom, mas a verdadeira questão era - por onde começar? Obviamente, essa não era uma situação na qual você pode executar o StackOverflow em busca de exemplos anteriores. No entanto, tendo discutido a idéia com amigos e colegas (todos decidiram que eu havia me mudado), comecei a redigir minha idéia.
Decidi que o programa de demonstração deveria ser escrito em código de máquina de 8 bits para o Commodore 64 usando o editor de código VS. A origem será processada pelo repositório Git no ADO e o pipeline de CI / CD será responsável pelas compilações, módulos e implementação no Azure. Eu já comecei a suspeitar que meus amigos estavam certos e meu teto já havia sumido, mas ainda assim essa ideia parecia um desafio interessante.
Escolha do Editor
Todo mundo sabe o ditado sobre como escolher a ferramenta certa para um trabalho específico. Isso se aplica às tarefas domésticas, à reparação de automóveis e à redação de códigos.
Como desenvolvedor .NET, passo a maior parte do tempo no Visual Studio 2017. Se precisar mudar para um projeto Java ou gravar programas Android nativos, inicio o IntelliJ ou o Android Studio, respectivamente. Qual editor devo usar para o código de máquina C64?
Você quer - acredite ou não - mas hoje existem vários bons editores adequados para escrever CBM. Eu brinquei com alguns deles, mas na verdade eu queria usar o Visual Studio Code. Usei o VS Code para meus outros projetos, e me pareceu muito flexível, confortável, e a presença de integração interna com o git foi uma boa adição.
A desvantagem dessa solução foi que eu teria que sacrificar o destaque da sintaxe no assembler 6510 e apenas encararia o texto em preto sobre fundo branco. Esta situação não corresponde à minha afirmação sobre a "ferramenta certa".
De repente, decidi ir ao Visual Studio Marketplace e verificar se já existe alguma extensão para o VS Code adequada para resolver o meu problema. Fiquei agradavelmente surpreso ao encontrar várias extensões projetadas para trabalhar em assembler. Infelizmente, nenhum deles foi preso pelo ACME Cross Assembler que eu selecionei para o projeto.
Isso não me impediu e, não querendo reviver os aspectos monocromáticos do desenvolvimento dos anos 80, me enterrei na documentação sobre a criação de extensões para o VS Code. Alguns dias depois, lancei com prazer a primeira versão da extensão para o Visual Studio Marketplace.
E esse exercício acabou sendo mais útil do que parecia inicialmente.
Ao mesmo tempo, não me concentrei em escrever programas no assembler. Várias vezes tentei estudá-lo, mas geralmente me sentia entediado ou irritado e segui para outra coisa. Depois de criar o plug-in, não apenas aprendi sobre a mecânica de criação de extensões para o VS Code, mas também adquiri uma boa compreensão da sintaxe obscura e dos códigos de operação.
Armado com um editor adequado e alguns livros de programação antigos dos anos 80, comecei a escrever código. Muito rapidamente, recebi um programa de trabalho importando um arquivo de música no formato SID e reproduzindo uma versão de 8 bits da música Beatles When I'm 64 (essa é uma piada antiga dos usuários do Commodore, mas parece adequada para este projeto).
Até agora, eu compilei e testei o programa em um laptop. O código-fonte foi confirmado no repositório git; portanto, a próxima etapa foi a necessidade de criar uma compilação para a integração contínua.
Uma das habilidades impressionantes da ADO é a capacidade de lidar com praticamente qualquer situação de IC / CD. Pronto para uso, o serviço oferece muitas tarefas predefinidas, permitindo criar rapidamente cadeias de CI / CD para os projetos mais modernos em apenas alguns cliques.
Se suas necessidades não fazem parte do serviço básico, o Marketplace geralmente fornecerá muitas ferramentas adequadas diferentes. Se isso não funcionar, você pode esboçar um script do PowerShell que faça o trabalho necessário.
O problema óbvio do projeto era que, apesar da ampla variedade de recursos de serviço, a montagem cruzada e a imagem de disco para o Commodore 64 simplesmente não existiam. Obviamente, eu poderia criar uma máquina virtual especial no Azure com as ferramentas necessárias ou seguir o caminho do PowerShell, mas isso seria interessante?
Também não gosto de máquinas virtuais na nuvem e, para este exercício, queria usar agentes hospedados, portanto, tive apenas uma opção. Para provar a que todo o exercício se destinava, decidi que seria melhor criar minha própria extensão para lidar com todas essas tarefas.
Extensão ACME Cross-Assembler
A primeira extensão necessária para minha cadeia de ICs foi compilar meu código de assembler no código de máquina C64. Para fazer isso, eu precisava instalar o assembler cruzado em um dos agentes de construção hospedados.
Assembler é um programa que converte a linguagem assembler legível por humanos em código de máquina real projetado para um manipulador binário específico. Normalmente, o código da máquina é gerado para o processador usado na máquina em que é executado. O assembler cruzado dá o próximo passo na conversão de código, permitindo gerar código de máquina para outro processador.
Como mencionei, no meu projeto, escolhi o ACME Cross-Assembler, porque é recomendado para o desenvolvimento do Commodore. Ele também suporta uma ampla gama de outros projetos de 8 bits, como o Nintendo Entertainment System ou a família Atari usando processadores 65xx.
Levei a maior parte do dia, com base na documentação e nos exemplos fornecidos pela Microsoft e outras fontes, para escrever, verificar e publicar no Marketplace uma versão funcional da extensão.
Quando iniciada, a tarefa baixa automaticamente a versão mais recente do ACME Cross-Assembler e a lança com opções que permitem criar o arquivo final para a plataforma de destino. Uma das vantagens associadas à escolha do ACME é que a maioria dos parâmetros para a criação do programa é incorporada ao código-fonte, o que minimiza a quantidade de entrada que precisa ser definida na extensão.
Alguém tem um disquete emprestado?
O próximo passo na cadeia é transferir o programa para um formato de mídia compatível com o Commodore 64, ou seja, colocá-lo em um disquete. Os desenvolvedores também não enfrentam esse problema na vida cotidiana. Felizmente, existem aplicativos separados para esta tarefa.
VICE é o emulador mais popular para o Commodore. Ele possui não apenas muitos emuladores para cada um dos vários modelos do Commodore, mas também várias ferramentas úteis, incluindo o gerenciador de disco virtual c1541. As imagens de disco criadas com ele podem ser usadas com o emulador, copiadas para mídia física (disquete de baixa densidade de 5 ") ou baixadas para o microSD e usadas com o emulador de unidade SD2IEC.
Diferentemente da tarefa ACME, que obtém todas as configurações do cabeçalho do arquivo de origem, o utilitário de disco c1541 conta com a CLI e o usuário tem muitas opções para gerenciar o disco. Para a minha extensão, decidi me concentrar apenas nas propriedades necessárias para a minha tarefa, mas, mesmo assim, enfrentei uma escolha relacionada à profundidade necessária para realizá-la.
A Commodore lançou três modelos de unidades diferentes, diferindo na maneira como lidam com volumes de disco com base na formatação e no tipo de mídia. O modelo básico, familiar à maioria dos usuários, só podia funcionar com unidades de um lado com capacidade de 170 KB (sim, kilobytes. Pergunte aos seus pais). O modelo posterior, 1571, usado no Commodore 128, poderia funcionar com unidades de dupla face, cujo volume aumentou para 340 Kb. Decidi adicionar flexibilidade à extensão, então adicionei suporte a vários formatos de disco como uma configuração, que pode ser selecionada na interface através do menu suspenso.
Como eu já tinha um exemplo de trabalho, a criação dessa extensão foi muito mais rápida. Aprendi algo novo que me permitiu melhorar o código da extensão ACME também.
Como no caso do cross-assembler, o software necessário é baixado do repositório de projeto de código aberto e instalado no agente de construção. A tarefa cria uma imagem de disco no formato desejado e, em seguida, o arquivo da tarefa de construção é copiado para ela. O arquivo resultante é movido para o diretório Build Artifacts, onde você pode baixá-lo.
O que acontece - tanto trabalho e, como resultado, você precisa baixar o arquivo? Este deve ser um material de treinamento de CI / CD. Se precisarmos provar nossa posição, precisamos implantar o programa na máquina para que possa ser usado como demonstração.
Floppinet desativado
As versões em execução de um computador Commodore 64 real e uma unidade 1541 são raras, sem mencionar que são grandes e pesadas. Além disso, eles não conseguem exibir imagens em monitores modernos sem adaptadores especiais, e isso limita bastante a eficácia da demonstração.
O Commodore SX-64 (o primeiro computador colorido "portátil" a ser fabricado em grandes lotes) tinha um monitor embutido, mas era do tamanho da minha mala de mão e pesava cerca de 10 kg. Imagine como seria difícil passar pelo serviço de segurança do aeroporto com um monstro desses?
O
C64 Mini, lançado recentemente, é pequeno o suficiente para viajar, a capacidade de baixar programas de USB e uma saída HDMI. Em alguns casos, essa seria uma opção. Mas ele ainda não alcança o objetivo desejado.
O verdadeiro problema não é a portabilidade do ferro, mas a falta de automação. A necessidade de transferir o programa de um laptop para um carro usando uma unidade flash não revela totalmente os recursos do ADO na apresentação.
Opção sem servidor
Como mencionei, o VICE é o emulador mais popular do Commodore. Foi portado para Windows, Linux, Mac OS X, MS-DOS e muitos outros sistemas operacionais. No entanto, para o desenvolvimento da nuvem, essa opção exigiria a configuração da VM como host, e eu queria seguir com uma solução que não requer um servidor.
Além das versões mencionadas, o VICE tem uma opção para JavaScript que funciona bem na maioria dos navegadores. Embora o desenvolvimento do front-end não seja o meu elemento, consegui criar uma página responsiva decente.
Para organizar a cadeia de liberação, carrego um arquivo com uma imagem de disco em um diretório no mesmo repositório. Associei isso à chamada do Azure Function App, que retorna uma lista de imagens de disco disponíveis. A seleção de uma delas no menu suspenso é carregada e iniciada automaticamente em um emulador de JavaScript.
O sistema funciona não apenas com o meu programa; eu consegui criar uma cadeia para implantar e executar o programa no Commodore 64 BASIC.
10 PRINT "HELLO WORLD"
20 GOTO 10Nós terminamos
DevOps para Commodore 64? É impensável!
O significado deste exercício não é apenas a prova de que, quando eles dizem sobre o Azure DevOps que oferece suporte a "qualquer idioma e qualquer plataforma", eles não significam apenas tudo relacionado à Microsoft (embora a versão BASIC para Commodore tenha sido comprada sob licença da Microsoft). Isso nos distrai da concentração em aspectos tecnológicos e faz as pessoas irem além da estrutura artificial que eles designaram para si mesmas.
Independentemente das desculpas, declarações como “isso não vai funcionar aqui” são muitas vezes equivalentes às declarações “sempre fizemos dessa maneira, por que mudar alguma coisa”. Ambas as frases demonstram relutância em crescer e se desenvolver, se adaptar a um cenário tecnológico em constante mudança e superar os desafios impostos por essas mudanças rápidas e agressivas.
DevOps não são ferramentas. As ferramentas no final são apenas um meio para atingir um fim, independentemente de quem as publica.
Para que o DevOps seja bem-sucedido para a organização, é necessário mudar a maneira de pensar e desenvolver nossa cultura corporativa. Precisamos aceitar muitas idéias novas, repensar o que achamos que sabemos e nos afastar de pensamentos como "isso não vai funcionar aqui", porque ainda não tentamos isso antes.
Criar uma cadeia de CI / CD para um computador de 30 anos não tem valor para os negócios, exceto para ilustrar claramente esse ponto de vista.