-1

I've been debating promoting code vs promoting binaries.

Are best practices the same or different in web vs native application.

I seem vaguely to remember a mantra promote code not binaries.

A couple folks in lead nroles at company I work for are saying we should build one docker image with the code and promote that. In this case its webdev and since client side code is served statically they expect it to magically take on dev, test, or prod without recompiling. Think single page framework. I suggested server side rendering or else we would have to post a rest call, put it in a header or in url like host name then handle it in client code. They said all those options had code smells including server side rendering.

I worked in several companies that deliver os's and native applications. Seems to me the promote code not binaries seems to make since because you may have different audiences within for example your dev, test, and prod. If you are testing a new feature in os but you have your staff using these test builds as dog food you compile a separate build with flags turned off so they dont leak the feature for example.

Just wondering what people suggest and what are some definitive resources on it. Seems like its devops territory and I come from mainly coding.

Currently promote code.

Improve this question
1

1 Answer 1

Reset to default
1

IMHO a simple answer would be that you should promote something immutable. In the case of images, that's easy: build an image once then follow the "deploy then test" path to production.

For static content, if you don't want to or can't package it up, use something else immutable for your promotion. For example, have you pipeline grab a specific git revision of a code repo, then do your static analysis, linting etc on your static files. Then push that precise git revision to your various non-prod hosting locations through your pipeline on your path to production.

Immutability is the key. Without being certain that you are deploying and testing the same thing in every stage through to production, you don't know if that production deployment is safe to do.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Appreciate the well thought-out response, I had a thought afterwards that maybe in our case builds were too monolithic. In case of feature sets could create a immutable image from a bom for different audiences without recompiling. In case of web app, may be an api config in the assets folder that is maintained by kube.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.