I have started to use versions and environments for release management such that we have separate development, test, and production environments. I would like to have a parallel setup on the webhook side such that the development Dialogflow CX environment points to the development webhook, etc. However I have been unable to figure out how to specify different webhook URLs, authentication, etc. for the different Dialogflow CX environments.
There is no mention of this in the documentation or API. Anyone have any experience with this?
Related
We want to build SAAS platform based on ms botbuilder. Specifically now we want to have many telegram bots on one backend (web app), instrumentation such as creation Bot Registrations, if needed, should be automated (prob except of creating a bot in telegramm).
I can't find any docs on how to address that but i guess theres 3 options:
1) Use directline api and create own adapter to speak with telegram api.
2) Use Azure script to create Bot registration. But i can't find a place where in web app configure app id and secret, these now are written in env vars on azure.
3) somehow deploy varios middlewares or enviroments (or slots) for each such registration. Lacking info on this aproach too much.
Maybe also some other options i'm not aware of?
I have a NS app that talks to a web api backend. I do not want to hardcode the api base url in the app itself because I need to be able to use different urls for development, testing, and production for different versions of the app.
E.g. Version 1.0 is in production and is pointing to https://someapi.com. I am currently working on version 1.1 and I want to point that to https://dev.someapi.com during development and testing because I have API changes as well. Once this version is QA'd and passes app store validation agains the test API. I will push it to production, deploy the API, and point the version 1.1 from https://dev.someapi.com to https://someapi.com.
Currently, I have a database table that has the api endpoint for each version and environment, so if I needed to QA the app for version 1.1, I query the database when I load the app and get the api endpoint for this version and environment.
Is there a better way for doing this?
Thanks.
Use environment variable with Nativescript CLI & Webpack. You may configure the URLs based on what environment you are building the app for.
There are lot of similar other ways around if you go through Webpack docs.
Say I have a front end node and three backed nodes tools, blog, and store. Each node communicates with the other. Each of these nodes have their own set of languages and libraries, and have their own Dockerfile.
I understand the DevOps lifecycle of a single monolithic web application, but cannot workout how a DevOps pipeline would work for microservices.
Would each micro-service get its own github repo and CI/CD pipeline?
How do I keep the versions in sync? Let's say the tools microservice uses blog version 2.3. But blog just got pushed to version 2.4, which is incompatible with tools. How do I keep the staging and production environments in sync onto which version they are supposed to rely on?
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest location of this service?
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices for developing locally with several different services?
Where can I go to learn more?
Would each micro-service get its own github repo and CI/CD pipeline?
From my experience you can do both. I saw some teams putting multiple micro-services in one Repository.
We where putting each micro-service in a separate repository as the Jenkins pipeline was build in a generic
way to build them that way. This included having some configuration files in specific directories like
"/Scripts/microserviceConf.json"
This was helping us in some cases. In general you should also consider the Cost as GitHub has a pricing model
which does take into account how many private repositories you have.
How do I keep the versions in sync? Let's say the tools micro-service uses blog version 2.3. But blog just got pushed to version 2.4, which
is incompatible with tools. How do I keep the staging and production
environments in sync onto which version they are supposed to rely on?
You need to be backwards compatible. Means if your blogs 2.4 version is not compatible with tools version 2.3 you will have high dependency
and coupling which is going again one of the key benefits of micro-services. There are many ways how you get around this.
You can introduce a versioning system to your micro-services. If you have a braking change to lets say an api you need to support
the old version for some time still and create a new v2 of the new api. Like POST "blogs/api/blog" would then have a new api
POST "blogs/api/v2/blog" which would have the new features and tools micro-service will have some brige time in which you support
bot api's so it can migrate to v2.
Also take a look at Semantic versioning here.
If I'm deploying the service tools to multiple different servers, whose IP's may change, how do the other services find the nearest
location of this service?
I am not quite sure what you mean here. But this goes in the direction of micro-service orchestration. Usually your Cloud provider specific
service has tools to deal with this. You can take a look at AWS ECS and/or AWS EKS Kubernetes service and how they do it.
For a monolithic application, I can run one command and simply navigate to a site to interact with my code. What are good practices
for developing locally with several different services?
I would suggest to use docker and docker-compose to create your development setup. You would create a local development network of docker
containers which would represent your whole system. This would include: your micro-services, infrastructure(database, cache, helpers) and others. You can read about it more in this answer here. It is described in the section "Considering the Development Setup".
Where can I go to learn more?
There are multiple sources for learning this. Some are:
https://microservices.io/
https://www.datamation.com/applications/devops-and-microservices.html
https://www.mindtree.com/blog/look-devops-microservices
https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/multi-container-applications-docker-compose
I'm using AppSync with Lambdas. To do so, I use the serverless framework.
I have few questions about the way you manage your serverless project with it's dev/test/prod versions.
I currently use the --stage option like sls deploy -s test to have multiple version. But if there is a problem after a deployment I can't rollback so I wonder if I should deploy with a new name all the time and remove the preview version later?
EDIT: I've found this that should do it for lambdas but will that work for AppSync?
How do you manage your dev/test/prod versions of AppSync and Lambdas?
Using API versions would be great except there are no cross-API subscriptions. Your mutations in one API won't trigger subscriptions in another. I'm hoping AppSync will come to support some sort of API versioning.
Not sure if serverless rollback works with AppSync, they probably should. However, it's just using serverless's S3 bucket cache, it's not a CloudFormation feature. Therefore, you could pretty much use version control to roll back changes and re-deploy just as well (your use case may vary).
We do have dev and test stages in one AWS account and prod in another AWS account. In test stage we can test that the API is working correctly before deploying it to production.
For our other deployments we also have beta stage before production but for AppSync this isn't possible because of the cross-API subscription issue. We can't have some data changing in production through beta API and not triggering a subscription in production API.
is there a way to setup Heroku to get a notification you when your config variables are updated?
thanks a lot
sorry for the very late reply, but I spoke with Heroku back then, and they said that it wasn't something that they did at the moment.
Very late to the party here, but just to give an updated answer. Heroku has support for webhooks so you can monitor those + more events on your end.
If you rather not build your own consumption pipeline, consider using LightFlare (I'm the creator) that has out of the box support of consuming Webhooks events from many services (heroku included) and notifies you at your choice(s) of destinations (slack / email etc ...).
LightFlare currently supports monitoring on services like:
Infra: GCP, AWS, Azure, heroku
Code/release: GitHub, bitbucket, netlify
Commerce: shopify, gumroad
More integrations based on our customers asks