Spearheading some of the efforts to integrate advanced AI capabilities into the Travis CI ecosystem. This involves leveraging my expertise in MLOps and LLMOps to implement innovations like Natural Language Processing for configuration files, real-time syntax checking during .travis.yml editing, and a customized AI model tailored specifically for Travis CI. I'm also working on live auto-assistance tools that will enhance the real-time editing experience, making our already simple YAML format even more efficient. We are saving the trained classifier model using Pickle for easy deployment and integration. With these AI capabilities, I am helping Travis CI stay at the forefront of applying AI to improve the developer experience with CI/CD workflows using the Travis CI platform.

Currently working on Travis Quickstart from May 2024 and will be working on it until August 2024. You can define your build with building blocks it offers, or with the help of AI you can get a .travis.yml fixed, or it can give you a helping hand. Authored by Michael Mendy for Travis CI, GmbH - 2024.

I list some of these experiences on ORCiD: https://orcid.org/0009-0009-7107-3112

Doing daily SRE tasks, this involves Perforce administration, doing complex work streams, depots, streams. Completing complex tasks in Perforce, Subversion, Helix Swarm, and of course Travis. This includes very complex migrations, for example, converting newlines. Migrating Windows to Linux instances can be complex when the native case-handling behavior of a Perforce Helix Server on Linux (case sensitive) is being migrated off of a non-native case-insensitive behavior of Windows, also using methods of Chaos engineering—implementing TCP checks using DataDog, and making these check scripts more Pythonic.

Network tuning with sysctl, doing high-end configurations in extreme cases where performance is critical and other methods are not helping or working—reconfiguring a breakout-auth server, mitigating downtime when migrations happen—debugging Git—adding storage for customers using Bastion via Debian—listing random failure specs and setting up SSL, DNS, and custom triggers for Helix Swarm. Using the DataDog SaltStack formula to apply policies and manage secrets. Using ELK to deploy ingestor modules.

Worked in tandem on occasion directly with Perforce making internal software to make things a lot more proficient and streamlined for us and adding functionality to already open source Perforce tools.

Partially I'm working on how to design TLS 1.0 to work with TLS 1.2. using Load Balancers so it can work with more Perforce instances.

I am focusing on integrating Travis into other products within the Idera DevOps suite, particularly Assembla. I'm also building encryption tools for e2e connectivity with Travis and Assembla. This will allow Travis to talk to Assembla and Perforce. Instances are remotely utilizing Azure Bastion, doing internal monitoring with DataDog, using RabbitMQ for clustering and failover, and using Argo for multi-tenancy and RBAC policies for authorization and drift detection. Added "salting" methods for software signatures to ensure the software you're pulling is what it says it is.

I also manage external resources and automate various infrastructure tasks with Terraform that are reusable across our on-prem solution—working with clients like Stanford University, Harvard University, NIH, The AMA (American Medical Association), St. Jude's Children's Hospital, United Nations, MIT, Dartmouth and Google to name a few. I occasionally use Nomad as a scheduler and orchestrator to deploy and manage containers. I also work with Terraform creating policies to help streamline processes in our infra. The Nomad scheduler for edge workloads has a relay function I've invented and is proprietary to Travis CI and Assembla.

Working with a small team of about five people to deal with all things Travis making sure our Travis workers go out, scheduling, and keeping up the Docker images. Analyzing our Travis build logs to identify development-unrelated build breakages and fixing them makes it clear whether (mis)using specific CI configurations can lead to a trade-off between build breakages and, in turn, cause a burn rate on your build times.

Even with the above issues, I work on daily; I try to lower the proportion and frequency of long build durations. I am using RabbitMQ for grouping projects into four quadrants based on median build durations and breakage ratios. From there, I triage the problem, then deploy the fix, whether it's RabbitMQ, Kubernetes, AWS, or Docker-related.

As a Python and Django developer at LASOR, an agile research organization, I contributed to studies on the progression of Non-Alcoholic Fatty Liver Disease (NAFLD). With NAFLD impacting 25% of Americans and no viable treatment options, LASOR aimed to reverse this trend through data-driven research and partnerships across medicine, technology, and industry. My role involved leveraging analytics to advance LASOR's mission of combating NAFLD.