Posted on Jun 29 • Originally published at lockhead.info As Matt already wrote in his project introduction post we have been using Amazon Codecatalyst to handle all of our project activities. This gives a very good indication into where CodeCatalyst is already "ready for prime time" and where further adjustments need to be made in order to develop the service into a fully fledge, all-or-nothing, integrated DevOps service.The one pushing for using CodeCatalyst was myself, as I wanted to try out the new Amazon service that recently went "GA" after being announced at re:invent 2023 in a bigger team and in a real project. It was great fun - and we learned a lot, too! Let's look at some details.Our journey with CodeCatalyst started with a - very agile and intense - planning session using the "issues" component of CodeCatalyst. Given the nature of an hackathon, we created roughly the first ten issues in the system. Three of us were "new users" for CodeCatalyst, but they were able to quickly interact with the issues component - by default, this is a simple Kanban board and has a well structured user interface. One thing we directly missed was the ability to copy/paste images into comments within the issues...and to attach files to the issues themselves. Linking issues to one another is also only hardly possible right now.We used a simple workflow and did a regular planning (twice per week) and created/updated/closed more than 50 issues (of partly very small scope) throught the course of less than four weeks. Overall, the available functionalities were good enough for our project and supported our project.The four of us are (Community) Builders from the bottom and all we need to be happy is a Git repository that we can push code to :-)Of course this is not currect, but CodeCatalyst allows you to host you own, private Git repositories. You can have multiple repositories per project. In our case, we had decided to go with a mono-repo approach and so we strickly worked in a single repository. Working with the source code repository was "just fine" and working as expected. We also decided to merge as early and as often as possible to our "main" branch. The team however struggled in working with setting up Pull Requests and working in the UI when reviewing pull requests.The most problematic things: UI response time, working with comments on pull requests (e.g. threaded comments) and creating pull requests. The whole UI does not yet feel as "structured" as in other competitors (e.g. Github) - examples: PR title/description proposals when creating a PR, link in terminal/commandline that allows your to create a PR.Another thing we missed is "git blame" online - not to blame each other but to understand what changed and broke our "hacked" "hackathon" source code :-)Cool: the markdown rendering for files named *.md. Missing here: including local images is not possible.We started off building our workflows with natively available actions in Amazon CodeCatalyst - using the "cdk deploy" action to deploy out infrastructure and the "s3 deploy" action to deploy our front end - but quickly shifted away from that and switched over to using Github Actions within the workflow to allow building our Flutter application as a CDK asset. As our Continuous Integration pieces matured within our npm implementation, there was less reason to go back to the native actions as the CI part was handled through npm.Our current workflow and CI/CD pipeline:The main preference here is to allow a continuous deployment to our production environment. This goes through an intial "sandbox" deployment, promotes to a "test" environment and then deploys to "production". The pipeline is prepared to execute integration tests, but they are not yet implemented - which is the nature of a _hack_athon :-) This would definately one of the next things to change - adding real integration tests and also adding some security verifications.Our workflow is, as I mentioned, pretty basic - here an excerpt of it until the deployment to our sandbox environment:As you can see, a lot of the CD (and also the "deployment") runs within the corresponding task definitions in package.json.We would really love to open-source our whole projet, to give you the possibility to get involved and learn from what we build, but unfortunately Amazon CodeCatalyst does currrently not offer an Open Source or a "Readonly" view and forces you to create an account for CodeCatalyst - these are things that make it difficult for us as we cannot link to our sources.If you are an AWS Community Builder, please reach out to either of us in Slack and we can give you access to the project.One of the "hidden gems" of CodeCatalyst are the Dev Environments - also known as Development Enviroments. Essentially, its a "service in the service" similar to Gitpod where you can host your IDE or the environment that you develop on. In our project we all didn't use it as the architecture was small and we only had this single project. Also, we were developing mainly on our main machines without switching between machines too often. That's why we all did not consider really using the DevEnvironments for this project. Last but not least, Flutter is not natively supported on the Dev Environments which would have forced us to prepare a devfile that includes the Flutter dependencies - and thats something that would have taken too much time out of the project.Still, the De Environments within CodeCatalyst are hidden gems that I believe should get more traction than they are getting until now. For a hackathon like this (3-6 weeks working time) CodeCatalyst seems to be a very good choice for a project that starts with a "new" or "fresh" codebase. The tool has most of the minimal requirements implemented to allow simple project management and good integration with AWS.It also allowed us to quickly get started and to collaborate on our sources.We really missed workflow notifications as well as manual approvals in the workflows.As the tool matures I personally hope that more and more AWS internal teams will be using CodeCatalyst to develop, plan and deploy out their internal AWS services and with that the "flow" in the User Interface will definately be improved, too - as today there are some hickups in a real developers workflow.And, last but not least - we would love to share this project with you, but given CodeCatalyst does not allow to "Open Source" a project, that's not possible :-)Maybe something for the next hackathon?If you would like to get involved in this project and help us to shape and build our AWS Speakers directory to make it easier for AWS User Group Leaders to find speakers - please reach out to either of us four about collaborating!Who to reach out to?Danielle, Matt, Julian or myself.Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Michael Levan - May 24 Andreas Bergström - May 24 Florian Lutz - May 24 Kenneth Kimani - May 23 Would you like to become an AWS Community Builder? Learn more about the program and apply to join when applications are open next. Once suspended, aws-builders will not be able to comment or publish posts until their suspension is removed. Once unsuspended, aws-builders will be able to comment and publish posts again. Once unpublished, all posts by aws-builders will become hidden and only accessible to themselves. If aws-builders is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Johannes Koch. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag aws-builders: aws-builders consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging aws-builders will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.