https://pulumi.com logo
Powered by
n

nice-cat-91582

09/15/2019, 1:31 AM
Hey folks - I'm going to be starting my first project on Pulumi in the next week or so. As I'm preparing myself and doing research, I have two questions that I haven't found satisfactory answers to. Wondering if folks in this community have good feedback: 1. How do your orchestrate database migrations? Do you just use an out-of-the-box library for regular apps, and kick it off in a lambda during each push? Or does Pulumi have a suggested way of doing this? 2. How do you develop locally? My reading indicates the answer is just "test driven development"... but I'm not sure that's always reasonable. One of my lambdas, for instance, will generate a PDF. It's gonna be way easier to develop that if I can actually generate a PDF and look at it, rather than trying to unit test PDF outputs.
t

thankful-optician-22583

09/15/2019, 3:10 AM
In my understanding, for lambdas if you want to manually test it, most people test it on the cloud it self (manual testing). https://medium.com/faun/how-to-effectively-test-aws-lambda-with-a-simple-strategy-46bda656200e
This article shows how to maybe replicate it locally. We use the pulumi kubernetes to run our apps locally by using the local context and deploying an image, mount a volume, curl it to test etc.
n

nice-cat-91582

09/15/2019, 3:17 AM
Yeah. The tricky bits for local are all the other dependencies... like if something is gonna write out to SQS, that's tricky. I've seen local stack as an option, but not sure how that works with pulumi
I guess I have this goal of being able to work when I have no internet connection... But perhaps that's unrealistic. In reality I can't remember the last time I did real development without internet. Usually when the network goes down I take it as an excuse to do something else :P
t

thankful-optician-22583

09/15/2019, 3:21 AM
So, I think with local stack, I used it with a docker compose such that it is in the same network with my app, if you use kubernetes, im thinking you can just create a configIp type service locally with the ports corresponding to each service (expose multiple service ports) you should be able to run it. Pulumi has a great K8s provider.
Copy code
const ingress_service =  new k8s.core.v1.Service("localstack", {
        metadata: {
            labels: deployment.spec.template.metadata.labels,
            namespace: "manual-test"
        },
        spec: {
            type: "ClusterIP",
            ports: [{name: "sqs", port: 4576, targetPort: 4576, protocol: "TCP" }, [{name: "S3", port: 4572 targetPort: 4572, protocol: "TCP" }],
            selector: appLabels
        },
    },
    {provider:provider}
);
so basically in your deployment object just pass in the local stack image, and then in your service object expose the ports you want to run,.
@nice-cat-91582
I have not tried this but this seems plausible.
ports correspond to these, https://github.com/localstack/localstack
l

limited-rainbow-51650

09/15/2019, 2:49 PM
For point 2, the aspect of 
unit testing
dissappears if you try to replicate your stack locally. TL;DR: Dissect your problem to smaller problems and unit test the smaller chunks Why not dissect your setup in a few unit tests: 1. unit test the function or method that transforms the Lambda input (e.g. a JSON) to the required input for the PDF generation 2. unit test a separate function or method which given some input creates a PDF. Validation e.g by http://www.pdfunit.com (Haven’t used my self but was the top Google search result) 3. unit test the post processing, e.g. sending the PDF as an email in a mocked setup. You no longer need Docker, replicated setups and alike…
💯 1
t

thankful-optician-22583

09/15/2019, 3:00 PM
I agree, I would think unit testing would be the best as well.
n

nice-cat-91582

09/15/2019, 5:26 PM
yeah, it's just that unit testing the visual bits of PDFs is a fair bit difficult. Once I lock in the rendering I can probably just test the inputs to the PDF generator, and trust that the renders will always be fine
and probably can hack around the previewing bit during development... have the renderer output to a local file, just while I'm doing the initial build
Powered by