CI/CD Practices in MuleSoft – CloudHub 1 vs CloudHub 2

Editor's Notes

• #6: Question about adoption of CloudHub 1 / 2 deploy & manage Simplified infrastructure Facilitates connection Adjust resources Tools to manage - monitoring
• #7: Architecture: HA zapytać dominika o architekture czy to jes tpodobny RTF Scalibllity: high resource effiencie fewer Vcores Enhanced Security: egress firewall rules out
• #8: Lets start with basics. Versioning is process of assign unique number to different states of application.
• #9: Of course - this is a joke but also a good introduction of generic versioning approach.
• #10: Label is optional
• #11: How we set version affects how Artifactory see the package. Snapshot might be built multiple times with same version It’s a marker for Artifactory, that these artifact should be stacked. Overall it means that they are unstable, development packages. Artifact without label or with RELEASE means it’s const package, that should end up in production
• #12: Remember, that we’re only scratching the tip of an iceberg here.
• #13: Code promotion is a concept of promoting code changes between branches. As our code usually goes through multiple environments, In this way of work usually each env has its own branch When it comes to deployment - it might be done manually or automatically. Easiest approach to automate in pipeline. Just trigger pipeline when new commit occur. Usually used in SF
• #15: Without going deep into specific branching strategy Everything that ends up in branch will be built and pushed to Artifactory with proper Version Deployment pipeline takes artifact from artifactory and upload it to runtime. As said earlier - Label is optional. No label means that Artifactory treat it as RELEASE.
• #16: Using Artifact Promotion approach we will encounter some puzzles to solve. Hardcoded properties - encrypted, but still it usually sits inside repository. Each incrementation of version is separate commit. Do not worry - Im going to explain how to approach these riddles.
• #18: CloudHub 1 works with both concepts But because of ease of use - Code promotion is widely used usually with minimal effort, for example: Build and deploy package using Mule Maven Plugin (mvn clean deploy -nsu -DskipMunitTests) Can be deployed from Exchange and from Local repository
• #19: It would be normal situation, but believe me, I’ve occurred such version on production application after a long time of running, and every iteration has the same version.
• #21: Application has to be in exchange Exchange acts like artifactory but it isn’t one Since CH2 is based on kubernetes, it needs artifactory.
• #22: To make the presentation as valuable as possible Lessons learned that we gather while working with clients with CH2, since either you will migrate CH1 to CH2 or start new project on CH2. CloudHub 1 is not available for new clients.
• #23: Let’s go back to versioning As I said about pom.xml, most of the times version is hard coded as static value Each change requires separate commit Our solution to that [ANIMATION] use dynamic variable with GIT TAG GIT TAG SHOULD REFLECT ARTIFACTORY STATE
• #24: HYPOTHETICAL System changes access credentials Mule app has to update props Steps: Commit changed props Rebuild and deploy app Backmerge to previous branches
• #25: Config server is just a place where we can store vars and secrets Tower is an example, written by one of my colleagues - co-creator of Bridging The Gap blog We can use Azure Vault as well In example, usage of Properties Provider for Azure Vault.
• #26: Few important things. We cannot use Secure Configuration Properties As our tests shown, when used, Mulesoft gets “key” to decrypt variables from runtime properties Then it does not use anything else that has been provided, either by Property Provider or via runtime props. To avoid leaks in secure keys - always use mule-artifact.json in CloudHub 1 and special property with name “Secret Environment Variables” in Anypoint CLI when passing secrets. That will block view of selected properties in Anypoint.
• #27: More information on next image - since it’s easier to explain usign visuals We cannot put some commit between old commits without breaking a repo or rewriting history of repository YOU SERIOUSLY DO NOT WANT TO DO THAT EVER. PERIOD.
• #28: Since 1 5 0 has features, that cannot go into production we have to fix current production version which is 1 2 0. Only way to accomplish that is create maintenance branch, that will last till 1.2 release is going to be used. We have to also remember about back merge to main branch.