I have a website on AppEngine that is 99% static. It is running on Python 2.7 runtime. Now the time has come to evolve this webapp, and since I have almost none Python code in it, I'd prefer to write it in Go instead.
Can I change runtime from Python 2.7 to Go, while keeping the project intact? Specifically, I want to keep the same app-ID, the same custom domain attached to it, the same SSL certificate, and so on.
What do I have to do in order to do that? I surely have to change runtime in the app.yaml. Is there anything else?
Bonus question: will such change happen without a downtime?
I'd be grateful for any links to documentation on exactly that (swapping runtime on a live app). I can't find any.
Specify a runtime as well as a new value for version. When deployed you'll have an older version that is Python and a newer version that is Go. There won't be any downtime (same as when deploying a newer version of Python).
Rather than trusting links/docs (that may be out of date or not 100% exactly what you're trying to do), why not create a new GAE-Std project for testing purposes and try it yourself. Having a GAE-Std test project is good for testing new function (especially by other testers who won't have access to the dev environ on your laptop).
The GAE services offer complete code isolation. So it should be possible to simply deploy a new version of the service, which can be written in a different language or even use a different GAE (standard/flex) environment. Personally I didn't go through a language change, but I did go through a split of a single-service app into a multi-service one, I see no reason for which the same principles wouldn't apply.
Maybe develop the new version as a separate app first, to be able to test it properly without risking an accidental impact on the old version and only after that bring the code as a new version in the old app. That'd be using the GAE project isolation. You can, in fact, test the entire version migration as a separate app if you so desire without even touching the existing app. I am using this technique - a separate app ID - to implement a staging environment for my app, completely isolated from my production app, see How to copy / clone entire Google App Engine Project
Make sure to not switch traffic to the new version at deployment time. This keeps the app working with the old version. Test first that the new version works as expected using Targeted routing. Then maybe use Splitting traffic across multiple versions to perform A/B testing with just a small percentage of the traffic going to the new version. Finally, when happy with the results, switch all traffic to the new version.
You need to pay special attention to the app-level configs (dispatch, cron, queue, datastore indexes), shared by all services/versions. They need to be functionally equivalent in the 2 versions. The service isolation doesn't apply to them, only project isolation can ensure no impact to the old version.
There should be no need to make any change to the app ID, custom domain mapping or SSL config. The above mentioned tests should confirm that.
A few potentially interesting posts related to re-working services/modules:
Converting App Engine frontend versions to modules
Google App Engine upgrading part by part
Migrating to app engine modules, test versions first?
Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?
Related
In trying to deploy a laravel project to a flexible environment in App Engine, I was hit with this message.
It has been two days now, any way to solve this while maintaining the same region for my project?
You can try deleting old versions of your deployment and/or consider reducing the resources you may need for your deploys (including max_instances). If you can't change this I think you should wait until there are resources or change your project to another region.
In addition, if your applications allows it, you can try on App Engine Standard Environment which does not use a VM in Compute Engine as the backend being this is my opinion the best option to maintain the same region for your project.
I have created a GCP Project and using App Engine standard environment for deployment purposes.
I have various developers working with me on the same project and deploying on App engine using various versions, however, we are using a default version to which all the traffic is allocated.
So are there any ways by which we can restrict the deployment on the default version. i.e we want specific people to be able to deploy on default version without removing deployment rights of other people on the same project.
And is there any alternative approach to this situation.
It depends on the runtime where you are deploying the application.
For example, in Python, if you are using the command gcloud app deploy (see the documentation), you can do the following:
gcloud app deploy --no-promote --version=<MY-VERSION-NAME>
The --no promote flag will avoid allocating all of the traffic to the version you are deploying, while the --version=<MY-VERSION-NAME> specifies the name of the version that you will create from the deployment, and replace an older one with the same name if it exists.
AFAIK there is no way to restrict deployment of a specific version. All access control method revolve around a certain identity being allowed access to deploy a certain GAE project or not. The version string used (i.e the version being deployed to in your approach) is irrelevant.
This falls into the "allows you to separate IAM roles" advantage mentioned in the accepted answer to Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?.
As a note: you're attempting to implement environments at the service/module version level, which is IMHO worse than both methods compared in that post, see Continuous integration/deployment/delivery on Google App Engine, too risky?
I have GAE application with 3 versions. Only default version has active instance, other two versions do not have active instances. Usually after deploy of any version, instance is created. But now that is not the case. Instances of non default versions wont to start after deploy, and I need those versions up.
I saw this question:
Google App Engine instances not starting
but there is no concrete answer.
Any idea how to start version instance?
The version will start after you send it the first request (unless you use Managed VM - https://cloud.google.com/appengine/docs/managed-vms).
It's unclear what you are trying to accomplish by having multiple versions running at the same time, having a little more info would really help providing a specific solution.
As #Vlad stated App Engine won't start (or keep) any app until it gets some traffic. you can start them by hitting ..appspot.com
If this "versions" are actually doing different things you should be implementing them as Modules .This way you can set up different rules for each module and setup the interactions between them.
I'm working on a very simple web app, written in Go language.
I have a standalone version and now port it to GAE. It seems like there is very small changes, mainly concerning datastore API (in the standalone version I need just files).
I also need to include appengine packages and use init() instead of main().
Is there any simple way to merge both versions? As there is no preprocessor in Go, it seems like I must write a GAE-compatible API for the standalone version and use this mock module for standalone build and use real API for GAE version. But it sounds like an overkill to me.
Another problem is that GAE might be using older Go version (e.g. now recent Go release uses new template package, but GAE uses older one, and they are incompatible). So, is there any change to handle such differences at build time or on runtime?
Thanks,
Serge
UPD: Now GAE uses the same Go version (r60), as the stable standalone compiler, so the abstraction level is really simple now.
In broad terms, use abstraction. Provide interfaces for persistence, and write two implementations for that, one based on the datastore, and one based on local files. Then, write a separate main/init module for each platform, which instantiates the appropriate persistence interface, and passes it to your main application to use.
My immediate answer would be (if you want to maintain both GAE and non-GAE versions) that you use a reliable VCS which is good at merging (probably git or hg), and maintain separate branches for each version. The GAE API fits in reasonably well with Go, so there shouldn't be too many changes.
As for the issue of different versions, you should probably maintain code in the GAE version and use gofix (which is unfortunately one-way) to make a release-compatible version. The only place where this is likely to cause trouble is if you use the template package, which is in the process of being deprecated; if necessary you could include the new template package in your GAE bundle.
If you end up with GAE code which you don't want to run on Google's servers, you can also look into AppScale.
My software team have just started using Jira to manage bugs, so I am fairly new to the process that is available to Jira.
The systems we build are internally facing applications or customer facing web applications, and we release to these environments on a change request by change request basis, rather than through a product lifecycle type of development lifecycle.
The way we plan to use Jira, is for each project (which is usually a single CR) to have its own project created in Jira. Our process is then as follows
Developers code and unit tests, until ready for integration testing
Developers start integration testing and any bugs are raised in Jira, under a version named Development.
Once all development bugs are fixed, we then move into QA, where we hand over the build to the testing team. A new version 'QA' is created, and all bugs found in QA are logged against this verison.
Once all bugs are closed, the project goes Live, and the project is closed in Jira.
From what I have seen of the more agile product type uses of Jira, I suspect we are using the version fields in the wrong way, but as I am new to Jira I am not sure if we are, or if there is a better way of doing it.
Would appreciate hearing from someone who has used Jira in this type of environment to see what the right way to use Jira is.
Here's what I'd recommend after using JIRA in a number of different environments, with varying team sizes and types of project.
Use JIRA projects to denote large but discrete functional areas of work that correspond to a subset of team members in your organization, e.g. a new web application or internal customer app.
If the project or the team working on it is big enough to warrant it, use JIRA components to define different functional areas. You can then assign component leads who will automatically be assigned new issues against their components, and you'll be able to track which functional areas have the most bugs and maybe need more attention from the test team.
For versions, you can certainly set up development, live and QA versions as you've described, but these are more traditionally mapped to the JIRA issue status. With the standard JIRA workflow an issue will be Open while a developer is working on it, Resolved after the feature or bug fix is completed, and then Closed if QA verifies the feature or fix, or Open again if QA identifies a problem.
If you have long-lived applications where you get multiple CRs that specify new features for the same app, I would use JIRA versions to define the different releases of the app, based on a feature set and / or time schedule.
With the approach above you'll be able to track the work of each team or individual developer / tester and know when all issues on an app have been addressed so that you're ready to do into test or deployment. I see you mentioned that you're not using a traditional product lifecycle, but unless your organization is very small and you develop apps that are thrown away after their first version is ready, I think you'll get a lot of benefit from this approach.