This week, I wrapped up the GitHub OAuth and App installation to enable users to create Jetpack Cloud projects with a single click. However, a design challenge surfaced:
- A user can be part of multiple teams and organizations.
- Each repository has a single installation of the Jetpack GitHub App.
Now, a question arises: If a team member grants GitHub authorization, does the same user authorize for all their teams? I'll tackle this puzzle next week.
Last week was mostly about finishing up edge case scenarios in the billing/payments page. We focused on covering all responses we may get from Stripe, how it will reflect what we show on the billing page, and what services users can access in each case. Besides that, we had a suggestion from a devbox user to add json schema for devbox.json. My 2nd focus was building and adding a schema to the schemastore catalog. This week, I'll incorporate that schema into our vscode extension for devbox so that users can get real-time validation on their devbox.json files.
Last week, I focused on integrating Google Cloud with our upcoming secrets product— lots of nailing down APIs and ensuring that GCP supports everything we want to do. There were also some discussions with Daniel and Mike about improving the ergonomics of TypeIDs, which we use internally for everything in Jetpack Cloud.
Here at Jetpack, we've been developing a Unified API service. It'll allow us to develop a common framework and infrastructure to ensure faster development and better security and minimize service "overhead" for the various backend services we wish to build. As part of this effort, I started rewriting the secrets service backend to work via this Unified API service this past week. The rewrite involved designing a protobuf API, and having good conversations around design conventions we wish to adopt for our protobuf APIs, and general code organization in this service. We also wished to move our backend secret store to a different cloud provider to better align with the upcoming Deployments product. So, I prototyped some operations using that cloud provider's SDK and proposed a few other backend designs. This exploration helped us develop a consensus design for securely storing secrets in this new backend store.
This week, I got the first version of our Unified API service deployed to production. The API implements dummy endpoints for now, but the infrastructure for building new endpoints and automatically deploying them to prod on merge is working.
I spent some time chatting with the team about improving the typeid-go, and wrote a few proposals. We updated envsec and devbox to use a new version of auth library that splits identity and access in preparation for paid and free plans.
Last week, I kept working on the Deployments tool. I focused on adding authorship checks so that preview branches only deploy if the commit author belongs to the organization or team that owns the project. That's to protect projects from being deployed by a non-member, who is not vetted and could be an attacker trying to compromise a project's associated secrets. However, the deployment will occur for production branches even if the author is a non-member. The reasoning is that prod branches are protected by default, and only authors with access can merge onto them.
Last week, I published the latest 0.8.0 release and a 0.8.1 patch release to address some issues users encountered while updating. This release has several great features and enhancements (including comments in devbox.json), which should make Devbox faster and more reliable.
I also attended Battery Venture's OpenCloud summit in SF. I met with founders from various SaaS and Cloud Computing startups. We had some great discussions and presentations on the future of AI, and how it will impact efficiency for developers and operations teams over the next decade.