I think it's common (and important!) to build your "production" image once and deploy it into a dev/staging environment first. This means there are no re-builds between deploys to each environment.
However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.
This is challenging because you probably don't want to include any build/test related packages in your production image (or layer) but you still want some level of confidence that your CI and Prod environments are the same.
I have often see builds pass automated testing but fail after deployment because our production Dockerfile/layer was missing packages or shared libraries that were present in the CI environment.
Why don't you want to include build/test related packages in your production image? Exactly because you mention you can't test the Docker image without these tools in the image, you cannot guarantee the production image works as you would expect it to work. Precisely because of that I think any packages that are required to run the tests should be part of the production image.
> However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.
When you say "automated tests" do you mean unit or integration tests, or both?
Because unit should generally be in your compilation process, not part of any image, and integration shouldn't require anything different in the image compared to any other environment.
Build it, which includes unit tests, and then deploy and integration tests should be run against your stable API.
Great question! In my experience with ruby on rails, the application runtime is so dynamic, that even unit tests may not be reliable if run outside the production image.
I think normally this isn't much of an issue because other automated/manual integration testing in the staging environments will catch any major problems, to your point.
Another example would be for browser testing via chromedriver. I've usually seen this implemented along side unit tests (i.e., prior to the build phase) but since it generally serves as an integration level test for many applications, this has lead to issues due to the testing and production environments being out of sync.
I think multi-layer Docker images are a compelling solution to this, but it's not usually how I've seen it implemented.
Instead, I've typically seen that test and prod environments are manually maintained. Sometimes these are two separate Dockerfiles or some shared CI environment managed by different teams.
> Another example would be for browser testing via chromedriver.
That shouldn't be in your master image. Put your application in a container, and either just run your browser tests and point it at your dev/test/prod deployment, or build a second image with Chrome driver and the test scripts and point it at your deployed application.
Doesn't need to be multi-layer, and it doesn't need to be complex. You have essentially two apps here.
Personally, I would like to see a markdown spec that eliminates parsing ambiguity by restricting the "edge-case" features that HTML is really much better at describing in a standard and structured way.
I think we could pick one way to handle emphasis, lists, and code blocks that covers a specific and predictable 80%.
Anything that becomes hard to describe without including additional notation to the grammar is probably best suited to be left as HTML, as was the intention behind markdown to begin with.
You can't bring up Feyerabend without mentioning Imre Lakatos. The "methodology of scientific research programmes" is another fun read that takes the matter of demarcation a bit more seriously than AM.
For example, Lakatos isn't satisfied with "anything goes" because it fails to consider the political and social consequences of being unable to recognize science from pseudoscience. For Lakatos, demarcation is necessary to maintain a "standard of objective honesty", and avoid falling into an "intellectual decay".
Overall, Lakatos is much less provocative than Feyerabend, but is equally invested in picking apart the historical nuances of scientific progress brought into question by Popper and Kuhn.
I recently picked up the Fellow Ode for myself. I'm very happy with it so far and it's working exactly as advertised. Quiet, consistent, and very fast.
Blink[1] is a really cool open source app that will give you a shell on iOS and allow you to SSH into another machine. You can install it yourself, or purchase from the App Store.
If you want to use another computer you own, rather than a server in the cloud, Tailscale[2] will let you easily connect when away from home.
The moka pot is super cool and I thought it made great coffee...until I discovered that I preferred almost every other possible brew method.
The moka pot is very hard to dial in and almost always burns the coffee. It requires care, focus, and attention. They're much more inconsistent than pour over and even the lever espresso machines I've used are less work.
I think moka pots are fun and worth experimenting with but I find it hard to believe people really love the results. But if you are always adding milk and sugar, then I can definitely see the appeal.
What is it that makes it hard to dial in? Is it the amount of heat? I had very little experience with moka pots until recently, even though I lived in Italy and the apartment I rented included at least five Bialetti pots varying in size from small to large - I didn't understand how they worked, so I never tried, and it was easier to just go outside to the nearest coffee bar.
But this summer I rented a motor home for the holidays (yeah yeah covid vacation -again), which came with a Bialetti. So I looked up how to use it, and every morning I would make a couple of cups for myself and the wife, on the gas stove.
Perfect coffee every time, very easy, no problems whatsoever. The gas stove I used was on max every time, no changes, so maybe that's why it was consistent.. but I don't really see how it matters, as the heat is just making steam after all. So how can you get burned coffee?
You can get burned coffee because the same container you use to heat the water to make the steam also holds the coffee and that still heats up. If you start with cold water that's more time for the coffee grinds to heat up and if you don't take it off the stove when it's done and cool it down right away that's time for the brewed coffee to start to burn as it's sitting in a heated hot pot.
Most other methods don't have you heat the coffee and the water together so you can only really burn it if you put it on a heating element after.
The main problem I have is that our range uses halogen elements. Which reach a specific temp then cycle on and off to stay there. You’re either too low temp. So the water boils then stops. Or too high, so it bubbles over and burns the coffee.
Done properly, steam shouldn’t be going through the coffee grounds in a moka pot. The expansion of the air (and evaporation of the water as well admittedly) in the lower chamber pushes the hot water up through them.
I've been making coffee on moka pots (both aluminum and stainless steel) daily for the past 30+ years and I have never experienced the problems you are talking about. On the contrary: I've tried a number of other coffee makers (french press, aeropress, percolator, …), but after a short time I wall always return to the moka pot.
Just now, because of this thread, I have ordered a Kamira Espresso maker. We'll see how it goes.
However, I think it's less common to run automated testing within the same Docker image you build and deploy to these environments.
This is challenging because you probably don't want to include any build/test related packages in your production image (or layer) but you still want some level of confidence that your CI and Prod environments are the same.
I have often see builds pass automated testing but fail after deployment because our production Dockerfile/layer was missing packages or shared libraries that were present in the CI environment.