A blog post overview is pending, but I've got a working example of a CI/CD pipeline here for those interested: https://gitlab.com/tolaeon/sdf-starter/-/blob/feature/test-sb-deploy/.gitlab-ci.yml

You mentioned having issues with TBA on gitlab. Did you figure that out?

Haha, ya it was a stupid issue. I had the tokenid and tokensecret in single quotes. Removed them, and voila.

Lol! Nice

So now all .SDF file variables go into gitlab environment variables and it's all good.

Good work!

This is nearly exactly how I had pseudo-coded it on my whiteboard. Awesome work.

@Miquel Brazil Thanks, I'm glad to hear. I can say that so far it has been a major productivity boost for my team. We have been using a more elaborate version of this for a few weeks now and it has reduced the time spent on releases and production errors significantly. We're able to catch many errors in the pipeline before they get into prod. Now prod deployments are as easy as pushing a button 🙂

@Brendan Boyd we just started splitting our “enhancements” and “core configurations” into self-contained projects for VCS and easier deployment. Originally we had one monolithic project that had been originally deployed as a bundle and it was a nightmare to release anything new. Changes were always out of sync because we would rush fixes by changing the components in the UI and then they’d be out of sync with the SDF. Or we’d implement a new feature in the UI and upload constantly changing script files and then try to consolidate them into an SDF and have a bunch of missing dependencies. Full SDF enhancements have been a godsend.

Yes, very cool

I like how your repo is like a starting template of sorts. One of the things I’ve been noodling over is how to make the template dynamic depending on the type of component being built, it can setup some preconfigured dependencies, etc. I’d also like to write a toll that can take all of the repos that constitute the project and make a single monolithic project that can be deployed in instances where a new Sandbox environment is created, etc.

What would you want to be different depending on the component?

so we’ve divided most of our features into functional areas and new enhancements are either within those scopes or a new one all together. of the known components there are some shared dependencies among them that would ease development if my junior dev for instance could run a generattor script or fork a repo (with an attached action that triggers whenn forked) to add in dependencies.

Are these dependencies that need to be imported into the project, or just added to the manifest?

just added to the manifest. we’ve created higher level projects that encapsulate core objects. for instance we have a project that includes all our custom roles. when we create a feature intended for a set of roles or group it would be awesoe to have those roles already included in the skeleton project

I'm not sure if this would work in your case, but you might consider having the manifest generated for each build/deploy. That's what we're currently doing here: https://gitlab.com/tolaeon/sdf-starter/-/blob/feature/test-sb-deploy/.gitlab-ci.yml#L41 Using this "answerbot" https://gitlab.com/tolaeon/sdf-starter/-/blob/feature/test-sb-deploy/answerbot

that’s exactly the sort of solution I’m thinking

Then it shouldn't matter if you have a bit of overlap

I’m thinking I might make a small challenge for myself and create a web UI where the dev could check off some details of what they plan to build and it downloads a .zip of the project template

So, in our case we don't edit the deploy.xml. That file stays very generic and we use git to build a dist folder of changes in a release.

gotcha. I like that workflow