Architecture as Code (AasC) aims to devise and manage software architecture via a human and machine readable and version-controlled codebase, fostering a robust understanding, efficient development, and seamless maintenance of complex software architectures.
This repository contains the Common Architecture Language Model (CALM) Specification, as well as capabilities being built to utilize the specification. This page lists the domains and capabilities being built by the official AasC community.
Whilst others are welcome to build their own capabilities, away from the AasC monorepo, we encourage you to join the community and contribute your projects to the AasC monorepo which has the benefits of being visible to the whole community; thereby attracting contributions and ensuring that changes to the manifest will be proactively built against your project.
| Project | Lead Maintainers | Builds |
|---|---|---|
| Common Architecture Language Model | @rocketstack-matt, @jpgough-ms |  |
| Docs | @rocketstack-matt |   |
| CLI & Shared | @aidanm3341, @lbulanti-ms, @willosborne, @grahampacker-ms @Thels |   |
| Translators | @Budlee @matthewgardner @jpgough-ms |  |
Architecture as Code is part of the DevOps Automation Special Interest Group. Our Zoom meetups take place on the fourth Tuesday of every month, see here for upcoming and previous meetings.
Have an idea or feedback? Raise an issue in this repository.
Architecture as Code operates as a monorepo, in here you will find both the CALM JSON Schema and the various projects that are being built to utilize the CALM specification.
We accept contributions via Pull Request, to make a contribution:
- Pick an issue you are interested in contributing to (or raise one yourself) and speak to the lead maintainers about what you plan to do either in the issue itself or come to a meetup. Some issues are suggested for first time contributors.
- Fork the repo (https://github.com/finos/architecture-as-code/fork)
- Create your feature branch (
git checkout -b feature/fooBar) - Read our contribution guidelines and Community Code of Conduct
- Commit your changes (
git commit -am 'Add some fooBar') - Push to the branch (
git push origin feature/fooBar) - Create a new Pull Request
There aren't many standards to follow when it comes to Github actions - but some good rules of thumb for this project are;
- GitHub actions should follow the naming conventions of pre-existing actions to maintain consistency. So that users can find other build-related steps in the same place.
- Ensure that any obscure actions are documented so that others can follow and maintain them.
Currently we have three typescript packages - two of which are managed via npm workspaces and one which is just raw npm. How these are built and manages slightly differs until they are all under the same worksapce - please look at their related github actions to learn how to build/test each of them.
Copyright 2024 FINOS
Distributed under the Apache License, Version 2.0.
SPDX-License-Identifier: Apache-2.0